Database Info

Stupid SU: Galaxy S 4 stock+root helper

Hi guys!
As some of you must have noticed, latest Samsung GT-I9500 firmwares carry a kernel configuration supposed to prevent SETUID privilege elevation.
Stock unmodified firmware with root is my preferred setup but also a strong dependency for all my development, for me this change is a massive setback if not a dealbreaker.
While poking around I found in about an hour something weird that reveled being a vulnerability, so I created a little thing to make it useful for now.
README:
Stupid SU: Galaxy S4 root helper by François SIMOND aka @supercurio
Circumvent an extremely weak false-security "Anti Root" mechanism implemented
on latest Samsung Galaxy S4 devices (on both Exynos and Qualcomm versions)
Preventing proper root function on official firmware breaks all my Voodoo apps
requiring stock+root and is a move that's hostile to both users and developers.
Samsung security might be embarassed by this proof of concept, as it defeats
their mechanism in a single line... not even with complex ARM assembler
but *one* line of shell script.
However, the goal here is to show Superuser solutions developers how to
deal with those devices for now, and provide a working solution to people who
bought a Galaxy S4 expecting to root it cleanly and easily but cannot.
This proof of concept is slightly slowing down Superuser calls, but its
"plain text" implementation has the merit of showing how stupid this exploit is.
SELinux configuration stays unmodified and active.
Features:
- Detect and supports both SuperSU and Koush's Superuser
- Installs Super SU binary by default
Make sure you have one of those Superuser apps installed:
- https://play.google.com/store/apps/details?id=com.koushikdutta.superuser
- https://play.google.com/store/apps/details?id=eu.chainfire.supersu
Root feature doesn't rely on a "StupidSU kernel" which is only an installer.
Feel free to flash back Samsung's original boot.img from their official firmware
after booting at least once.
Important Note:
This "exploit" is so lame that it will be fixed in no time, making updated S4
a pain to root again.
I wish Samsung will reconsider their "Anti Root" approach, which is damageable
in every regard and defective by design as demonstrated here.
Also, I'm simply not interested developing for and promoting devices from
manufacturers hostile to developers: It's just a waste of valuable time.
Click to expand...
Click to collapse
INSTALL
1/ copy rooting/ directory in your initramfs
Make sure "root.sh" file is has an executable permission (chmod 744 recommended)
2/ Add those lines at init.universal5410.rc end:
# Stupid SU
service rooting /stupidsu/root.sh
class main
user root
group root
oneshot
3/ Assemble your initramfs with the associated Samsung official kernel binary
of choice in a regular boot image
4/ flash as boot.img
5/ At each boot, Superuser app are detected automatically and su binary adjusted
accordingly.
Click to expand...
Click to collapse
Source code
On GitHub
License
Kernels downloads, only for demo purposes of the concept, you can flash back original Samsung boot.img once rooted
GT-I9500 Stock + root StupidSU v4 UBUAMDE
GT-I9500 Stock + root StupidSU v4 XXUAMDK
GT-I9500 Stock + root StupidSU v4 XXUAME1
What's next
Owners of Qualcomm Galaxy S 4 devices experiencing the same dificulties with Samsung the anti root strategy might want to try this method, please let me know if you're ready for some experimentations.

Supercurio pleas add thraed t General section i think ther well bee lots of testers for i9505.thx for suport
Sent from my LG-P500 using xda app-developers app

Going to try this on latest LE1 stock kernel now .....thread is in correct section
edit: did not work on LE1 kernel. I will try once again. DId any one tried the MDK kernel..I am having again the problem with SU binaries installation..
Edit: Thanks bro. working on ME1 kernel now. Did mistake while doing tar. Appreciate it! Root is working fine but cant update the binaries of Supersu, still the root works fine.

Here comes the master welcome to SGS4 development forum mate.. (rahulzeven from twitter here )

So the BEST thing's just happened?!:laugh::good:

i repacked the kernel of Samsung-Updates.com-KERNEL-GT-I9500-XSE-I9500XXUAME1-1367637350 using supercurio method. Root works fine. All we need to is install it from ODIN and dont update the binaries of supersu.
Download Link
Edit: New file uploaded

grgsiocl said:
i repacked the kernel of Samsung-Updates.com-KERNEL-GT-I9500-XSE-I9500XXUAME1-1367637350 using supercurio method. Root works fine. All we need to is install it from ODIN and dont update the binaries of supersu.
Download Link
Click to expand...
Click to collapse
Thanks fo much! Will Titanium Backup work on this kernel?

Hope chainfire will start working on mobileOdin soon. So much easier to flash than.
... tapat*lked

GSeeker said:
Thanks fo much! Will Titanium Backup work on this kernel?
Click to expand...
Click to collapse
wrong file uploaded. Please download the same in 5 minutes. Uploading is on and the kernel date should be MAY 04
---------- Post added at 12:33 PM ---------- Previous post was at 12:28 PM ----------
GSeeker said:
Thanks fo much! Will Titanium Backup work on this kernel?
Click to expand...
Click to collapse
it should work as i dont use titanium backup and instead i use gobackup pro and it works fine anyway

MDK from OP working good, thanks

grgsiocl said:
i repacked the kernel of Samsung-Updates.com-KERNEL-GT-I9500-XSE-I9500XXUAME1-1367637350 using supercurio method. Root works fine. All we need to is install it from ODIN and dont update the binaries of supersu.
Download Link
Edit: New file uploaded
Click to expand...
Click to collapse
I'm trying to repack the kernel of korean gs4,
but I am a noob in kernel devs.
I can edit ramdisc, but fist trying in initramfs, zImage.
Is rooting directory means both root.sh and files(folder)?
and paste them on first class route?
hope you give some advices.. thanks

aslak89 said:
I'm trying to repack the kernel of korean gs4,
but I am a noob in kernel devs.
I can edit ramdisc, but fist trying in initramfs, zImage.
Is rooting directory means both root.sh and files(folder)?
and paste them on first class route?
hope you give some advices.. thanks
Click to expand...
Click to collapse
when you unpack the kernel you will have two folders one is ramdisk and other one is split_img (zimage). You need to copy the folder stupidsu folder in ramdisk and modify the init.universal5410.rc as per OP stated and repack the image

grgsiocl said:
when you unpack the kernel you will have two folders one is ramdisk and other one is split_img (zimage). You need to copy the folder stupidsu folder in ramdisk and modify the init.universal5410.rc as per OP stated and repack the image
Click to expand...
Click to collapse
then, is not necessary to recompile zImage?
ok I m going to try it right now, thank you grgsiocl

muhamet said:
Supercurio pleas add thraed t General section i think ther well bee lots of testers for i9505.thx for suport
Click to expand...
Click to collapse
Yes in fact I was hesitating, but as soon as someone is ready to assist me to try on a Qualcomm device (I9505 or T-Mobile Galaxy S4) I'll make a thread here too.
grgsiocl said:
Going to try this on latest LE1 stock kernel now .....thread is in correct section
edit: did not work on LE1 kernel. I will try once again. DId any one tried the MDK kernel..I am having again the problem with SU binaries installation..
Edit: Thanks bro. working on ME1 kernel now. Did mistake while doing tar. Appreciate it! Root is working fine but cant update the binaries of Supersu, still the root works fine.
Click to expand...
Click to collapse
Great then

aslak89 said:
then, is not necessary to recompile zImage?
ok I m going to try it right now, thank you grgsiocl
Click to expand...
Click to collapse
The point here is to have stock (unmodified Samsung binary) kernel running, with associated modules and no other modification.
Which gives you several usage options:
keep the StupidSU stock+root kernel (same kernel binary, same kernel modules, only very slightly initramfs scripts) that will auto-root depending on which Superuser APK you installed
you can flash back the official kernel and still enjoy root the same.

supercurio said:
The point here is to have stock (unmodified Samsung binary) kernel running, with associated modules and no other modification.
Which gives you several usage options:
keep the StupidSU stock+root kernel (same kernel binary, same kernel modules, only very slightly initramfs scripts) that will auto-root depending on which Superuser APK you installed
you can flash back the official kernel and still enjoy root the same.
Click to expand...
Click to collapse
Thank you for awsering
then I repacked my kernel but still not work.
copyed stupidsu and edited init.universal5410.rc in ramdisk and repacked boot.img.
I guess permission is the thing,
attach my shots
hope you loot at once.
Sent from my SHV-E300S using XDA Premium HD app

walda said:
Hope chainfire will start working on mobileOdin soon. So much easier to flash than.
... tapat*lked
Click to expand...
Click to collapse
He will after he will come back from his vacation.

I'll look into a fixed CF-Auto-Root for the I9505 as soon as I'm back on Sunday. I imagine that will be tested by Sunday evening, with a I9500 test version available sometime Monday. If all is well
In StupidSU environment and for this initial release Koush's Superuser app would
be preffered as SuperSU main UI refuses to launch because it cannot detect its
original su binary. Aside from that both work as expected.
Click to expand...
Click to collapse
This is because you're not installing the backup su binary. The UI app detects this is missing and triggers an update. Bug in StupidSU

aslak89 said:
Thank you for awsering
then I repacked my kernel but still not work.
copyed stupidsu and edited init.universal5410.rc in ramdisk and repacked boot.img.
I guess permission is the thing,
attach my shots
hope you loot at once.p
Click to expand...
Click to collapse
Alright I'm adding some logging in my scripts so you'll be able to see what's happening − or not

supercurio said:
Yes in fact I was hesitating, but as soon as someone is ready to assist me to try on a Qualcomm device (I9505 or T-Mobile Galaxy S4) I'll make a thread here too.
Click to expand...
Click to collapse
Brilliant news!!!! Thanks a LOT!!
Let's make it work!! It will be AWESOME if I could use latest STOCK Kernel in my ROM's......
I'll give you a hand

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

[HELP NEEDED] [S7 SM-G930FD] stuck on boot animation after flashing boot.img

Hi all,
Im trying to flash a custom built kernel on a g930fd device running android 6.0.1.
ive did the following steps:
built the kernel - the source matches with the rom on the device
replaced the out Image using AIK
created a flashable zip and tried to instal it via TWRP.
another steps ive tried as sanity checks, ALL RESULTED IN BOOT ANIMATION LOOP:
1. dd out the boot.img form running device, dd that boot.img back to /dev/block/platform/*/*/BOOT
2. flash boot.img with odin
3. built dtb and Image and flashed in using Lazyflasher
IF SOMEONE KNOWS WHAT COULD BE THE PROBLEM, ILL APPRECIATE ANY HELP , THANK YOU.
@osm0sis i hope maybe you can help me with a valuble input thanks in advance!

Where's your source?

djb77 said:
Where's your source?
Click to expand...
Click to collapse
i got it from samsung opensource

qroot0 said:
i got it from samsung opensource
Click to expand...
Click to collapse
You do realise you still have to modify it in order to get it to work properly.
So where is YOUR source code? What's your github link?

djb77 said:
You do realise you still have to modify it in order to get it to work properly.
So where is YOUR source code? What's your github link?
Click to expand...
Click to collapse
Sorry,
heres the link:
github.com/IgalGokhman/8890-6.0.1-custom-kernel
Ive reverted the changes i made to the defconfig.
BTW, Its my first time building a kernel for samsung device, so im not sure about all the chhanges i need to make in order to run it on the device.
Ive read a lot through xda and othher forums but the majority of them just saying: run make and install using updater-script...

qroot0 said:
Sorry,
heres the link:
github.com/IgalGokhman/8890-6.0.1-custom-kernel
Ive reverted the changes i made to the defconfig.
BTW, Its my first time building a kernel for samsung device, so im not sure about all the chhanges i need to make in order to run it on the device.
Ive read a lot through xda and othher forums but the majority of them just saying: run make and install using updater-script...
Click to expand...
Click to collapse
Well, I really needed to see what changes you made to start with, because all I have in front of me now is clean source.
Most of us use a build.sh script of some sort which builds the zimage, dtb, and ramdisk. My script does it all, builds kernel and zip.
Here's my old MM kernel that you can have a look at:
https://github.com/TheGalaxyProject/tgpkernel-s7-mm
If you use any of this please give credit

djb77 said:
Well, I really needed to see what changes you made to start with, because all I have in front of me now is clean source.
Most of us use a build.sh script of some sort which builds the zimage, dtb, and ramdisk. My script does it all, builds kernel and zip.
Here's my old MM kernel that you can have a look at:
https://github.com/TheGalaxyProject/tgpkernel-s7-mm
If you use any of this please give credit
Click to expand...
Click to collapse
Thanks I’ll take a look.
I do have a build script, eventually I have an Image and a dtb.image, from both of them I make a boot.img with AIK.
I tried to build the kernel with the config values I pulled from the device /proc/config.gz and with the “as is” values in the arch/arm64/configs/exynos_8890_defconfig
Both boot.imgs bootlooped the device

[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: