Related
Hey all!
I've been following the CyanogenMod guide on compiling the kernel and I've successfully compiled a kernel for the 7510. The next step is now to create a flashable zip with there is a guide for here:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
According to that guide you are supposed to extract the boot and recovery to be able to unpack, edit and re-pack the images. However, when I type "cat /proc/mtd" in a root shell I only get the headers of the output "dev: size erasesize name" and no listing.
Anyone go an idea on how to extract these images to create something that can be flashed? Is there perhaps an easier and better way to do this?
Note that the kernel I'm compiling is pershoots ICS kernel and I'm doing this just for fun and learning... no glamour or ruined creds . Unforunately this means that it is probably not possible to repackage one of pershoots already created update.zip's (the 3.2 versions) with a different zImage?
I have not tried to compile a kernel yet, I'm trying to remember what I did last time to just get pershoots' kernel on the last build.
I think what I did was make a complete build from cyanogen source and then I used a windows OS guide to unpack and repack the boot.img with the new kernel. I'm sure that won't help you since you don't even have a kernel yet.
What OS are you building in?
It was real late at night last time I read about compiling a kernel, but I thing it requires extracting a working kernel from the device???
kmmxracer said:
I have not tried to compile a kernel yet, I'm trying to remember what I did last time to just get pershoots' kernel on the last build.
I think what I did was make a complete build from cyanogen source and then I used a windows OS guide to unpack and repack the boot.img with the new kernel. I'm sure that won't help you since you don't even have a kernel yet.
What OS are you building in?
It was real late at night last time I read about compiling a kernel, but I thing it requires extracting a working kernel from the device???
Click to expand...
Click to collapse
Thanks for your reply. I do have a kernel build already, it's baked and finished
I'm on Ubuntu, Mac and Win 7 if it's really needed (would hate to reboot my machine ). Perhaps the guide you followed is the one I linked to above? That is not working for me unfortunately since I can't get to the boot and recovery images.
Hmm, this has me confused now. Perhaps my flashing efforts have been working all along.
In the kernels I've compiled and flashed before, they have always showed my information in the "Kernel version" field in "About tablet". Thus I have been checking that field after my flashes and it hasn't changed once.
I've tried several different updater scripts and none has worked, or so I have believed. I became a bit suspicious about this and checked the build.prop for the ICS KANG ROM, and it has some properties that I think may be causing the confusion.
Under "# autogenerated by buildinfo.sh" ... there are these props among others:
ro.build.user=eric
ro.build.host=Venom
Wouldn't that be shown under "Kernel version" as [email protected] although I've flashed the kernel build on my system?
All the flashes I've done, most of them packaged from versions of Koush's AnyKernel script have gone through without warnings so perhaps my flashes have been working all along?
Running uname -a from the shell on the device gives this though:
Linux localhost 2.6.36.4-cyanogenmod+ #1 SMP PREEMPT Sun Dec 25 18:14:16 EST 2011 armv7l GNU/Linux
That would indicate that it was build on the 25th of december wouldn't it? Well, that's not today so in that case I have still failed .
Would someone be able to have a look at my zip to see if it's validly structured if I pm a link to it?
Thanks!
Perhaps that guide is a bit dated?
This is the one I used: http://www.freeyourandroid.com/guide/extract-edit-repack-boot-img-windows
kmmxracer said:
Perhaps that guide is a bit dated?
This is the one I used: http://www.freeyourandroid.com/guide/extract-edit-repack-boot-img-windows
Click to expand...
Click to collapse
Awesome, thanks. Will look into that.
I have successfully compiled source I downloaded from Samsung on Ubuntu build environment I set up myself and used toolchain to compile it. Everything went without a problem. When I flash the phone, it goes into download mode. My question is how can I troubleshoot the problem? I flashed the phone with a working stock image, and pulled the logs with logcat and searched it for various keywords ( tar, boot, image ) that might give me an indication of what is wrong. But I did not see anything that stands out. I basically used one of the scripts in beasttools kit to replace my zImage with the zImage of a working rom I downloaded from SamMobile. I'll be glad to provide more details, if this is the appropriate group to discuss it and someone is willing to have a look at what I have done.
NOTE: This thread is for the discussion of kernel development. If you don't recompile kernels, please don't post/reply.
After a couple years playing with nexus devices, I'm coming back over to Samsung (until I get bored) and I'm seeing that no one has managed to root a Note 5 device without a recompiled kernel. Why? Because using the stock kernel seems to result in just boot loops.
From what I've been able to observe, the custom kernels all have one thing in common in regards to allowing root to work: They are all changing sepolicy to run permissive instead of making modifications to allow 'su' to work in enforcing mode.
Why?
I have to be honest in saying that I haven't studied how @Chainfire had managed to get su working on the nexus devices while retaining sepolicy in enforcing mode, but it seems that this would be a far better solution than just neutering sepolicy all together.
Has anyone yet attempting to get a sepolicy enforcing kernel working with root? If so, are you willing to share what you tried and how things worked out?
My end-goal is probably to throw together a "as stock as possible" kernel that's root-able. If at all possible, I'm hoping that just some modifications to the ramdisk would be enough to get things working. However, I'd like to take advantage of any previous work done (if any) to get this working.
Thanks
Gary
Edit:
FOR CLARIFICATION. THIS THREAD IS NOT FOR GENERAL USER DISCUSSION. THIS IS FOR DEVELOPERS TO DISCUSS SELINUX, THE NOTE 5 KERNEL, AND METHODS BY WHICH ROOT CAN BE ACHIEVED WITHOUT CHANGING SELINUX TO PERMISSIVE.
Reminder,
Read the OP and stay on topic.
Thanks.
The_Merovingian
Forum Moderator
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
DAGr8 said:
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
Click to expand...
Click to collapse
I'm in the process of trying to modify the sepolicy in the stock boot image ramdisk to see if that allows root to work with the stock kernel (modified ramdisk.)
Wish me luck.
Dammit - all of my tools are out of date. Have to recompile mkbootimg, unpackbootimg, etc.
Okay, so I'm finding out all kinds of Fun Things that Samsung has done with this device...
First, at least some versions of this phone (mine is a 920i) have something in the stock firmware kernel(?) that restores factory recovery on first boot. This is my first sammy device in several years, but I seem to remember reading that other samsung devices have done this as well. (This is the reason that people are having to not allow ODIN to auto-reboot the phone.)
What's really pissing me off, however, is that if I allow TWRP to modify the system partition (based on the prompt on the initial boot) and don't actually make any system changes, the normal stock kernel won't boot... it gets stuck in a boot loop. (pre-bootanimation)
This is similar to the reports people are having of boot loops if they install root without changing the kernel. I'm starting to think it has nothing to do with actually being rooted, but that ANY system partition change is causing the bootloop. (Surprise!)
So, I decided to try something a bit different: I restored stock firmware (tar.md5 via odin) and after the reboot, I went back into ODIN mode. This time, I flashed TWRP and rebooted immediately back into ODIN and a flashed kernel with a modified sepolicy in the ramdisk. I then booted normally. My kernel loaded. I used adb to reboot to recovery. TWRP loaded. From TWRP, reboot normally.. it worked. Good start. adb reboot recovery, and this time I uncheck the option to "only mount system R/O." (It's in the "mount" section of TWRP.) Reboot system... and... BOOTLOOP.
(This has nothing to do with root. I'm not installing root... )
Time to start digging in the kernel ramdisk to try and figure this one out...
Tried the same as above, but with Philz compiled by @arter97. This time, I was stuck in a bootloop after the first time recovery ran. I'm guessing that this particular recovery will ALWAYS touch the system partition without first asking? Not sure... Philz did ask if I wanted to install root when I chose the option to reboot, but I declined.
Note to self:
http://forum.xda-developers.com/showpost.php?p=61542104&postcount=433
Just remove support_scfs,verify from the fstab and altering system will work.
Click to expand...
Click to collapse
I have NFC what "support_scfs" is, but I'll have to spend some time with google to figure it out. Perhaps a bit of SourceDiving. Won't have a chance to test this until tomorrow evening.
I love replying to myself. The truth is, I'm probably one of the few people who could stand talking to me. Of course, even I feel like killing me every now and then. It gets complicated.
Oh.. anyway.. I got it. A stock kernel with a modified ramdisk running selinux in enforcing mode and root-able. I want to spend a day running tests, but will post results of the results in about 20 hours. (assuming I get to sleep tonight...)
As well as gaining the enforcing selinux security (somewhat degraded by being rootable), this also ensures all hardware is working even if samsung "cheats" in posting source code.
(see attached screenshot... it's really the stock kernel and still enforcing SE for Android. )
Edit:
Then again, there's no harm in posting the boot image now. This is from a n920i device using the N920IDVU1AOH6 firmware. I'm attaching a file that can be unzipped and flashed with ODIN (AP slot.) Someone fluent should be able to pull the boot image out of the tarball and flash it directly with TWRP or even via 'dd' (assuming you're already rooted.)
(If you try to flash the .zip file directly, you deserve whatever horrible things happen to your phone.)
THIS IS NOT A RELEASE. THIS IS FOR DEVELOPERS WHO KNOW WHAT THEY ARE DOING TO FIND FLAWS WITH IN REGARDS TO ROOT AND SELINUX. I can't claim this would work for any device without the above mentioned firmware. If you don't know exactly how to recover from Bad Things, don't even download the attachment.
No support. No help. If you have to ask how to flash this or anything of the sort, this isn't for you.
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
garyd9 said:
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
Click to expand...
Click to collapse
Please, publish original boot.img from N920IDVU1AOH6
svadev said:
Please, publish original boot.img from N920IDVU1AOH6
Click to expand...
Click to collapse
Did you not bother to read any of the posts in this thread? There are known locations for stock images. This thread isn't one of them.
Read the very first line in the first post.
I made it for my SM-N9208, and it is really works with supersu 2.50 .
Thanks!
garyd9 said:
Changes from stock ramdisk:
1. Modify sepolicy as @Chainfire documented (ironically using an unrooted note 5) to allow supersu to work it's magic.
2. Modify fstab to remove support_scfs,verify from the mount options for the system partition. (this solves the boot loops)
That's IT.
One warning, though: This is using supersu beta 2.51. That's not released. Actually, I think it's flagged as a work in progress.
Click to expand...
Click to collapse
Hi
Could you please post a more detailed guide ? I want to do it myself for my n920c.
Thanks
geek78 said:
Could you please post a more detailed guide ? I want to do it myself for my n920c.
Click to expand...
Click to collapse
yeah. well, at least assuming you know how to unpack and repack boot images... (Because this stuff is very experimental at this point, and still very much a work in progress, you should have a certain level of proficiency before mucking with it. I can't and won't hold anyone's hand for this stuff at this point.)
you need to unpack the boot image. Get the boot.img and unpack. Open the ramdisk. In the ramdisk is a file called 'sepolicy.'
Start with this post to figure out how to change it:
http://forum.xda-developers.com/showpost.php?p=63190351&postcount=2071
Find the reply to that post from Chainfire to see how it can be done without a "reference" device.
You'll also have to change the proper fstab as I documented already in this thread.
Then pack up the ramdisk and repack the boot image.
Thanks. Perfect !
DAGr8 said:
I have to ask my friend. Since I'm back to Samsung at the same time as you it seems. I see very little advantage of running root atm but I see none of running Selinux non permissive. Also these devices being exynos you will not find much support for it.
I may be wrong but Selinux non permissive has been a problem on samsung custom roms from day one guys just disabled it and be done with I've never seen anyone complain ;p
Click to expand...
Click to collapse
I'm trying to place your name. Do I know you from SGS2 days or Note2 days?
Anyway, I'm not happy with settling. Never have been...
Edit:
Note or Note 2. Must have been Note2. You were doing smali edits for enabling tablet mode. That was pre-xposed days.
Edit 2:
To answer the question: enforcing selinux adds a layer of security on the device and blocks many security infractions. Basically, if you haven't been given permission to do something, you can't do it. Even as root. In theory, selinux could block the stagefright security issues. When a device is in "permissive" mode, selinux is there, but isn't actually blocking anything. It just logs violations and then ignores them.
In other words, permissive mode completely negates having the se extensions at all. Permissive was a mode that devs could run in to see what might break and what might not.
"root" access is, of course, a hole in the scheme. Chainfire, with supersu, has done quite a bit to ensure that the hole is controlled, but it's still a hole. However, a rooted device with an enforcing selinux kernel is still significantly more secure than a non-rooted permissive selinux kernel.
Another edit:
Here's some links:
https://su.chainfire.eu/#selinux
http://linux.die.net/man/8/selinux
<sarcasm> Wow, I almost forgot how much JOY and FUN it is working with Samsung sh!t kernels. </sarcasm>
So, in testing this (yes, I really DO test things.. imagine that) I found that my device wasn't going into deep sleep. Wow. How interesting. Oh, and not a single wakelock. WTF?!
Instead of google'ing first, I reverted to being a kernel dev (that is now trying to debug a kernel that he hasn't even compiled.) The first thing a kernel dev looks at: "dmesg" So, I copy dmesg to a file and transfer it my PC. (BTW, Notepad++ is God's gift to windows editors.) I search for various strings like "error" and "fail" and "suspend." What I end up seeing is a crapload of messages like this:
Code:
[0: system_server: 3858] PM: Device 0:0:0:x failed to suspend: error -5
(replace x with 1, 2, or 3)
Huh? So, before I dive into the code (because I really don't believe that samsung actually shares the kernel code that they use for themselves), I decided to google around a bit. I finally had enough search terms to hopefully narrow down the search results.
Guess what I found? People having the exact same problem on another samsung device: the S6 (and edge.) Here's the best of the threads:
http://forum.xda-developers.com/galaxy-s6-edge/help/deep-sleep-t3079705
It gets into some interesting detail around page 4 and 5. You'll have to skip past all the clueless people preaching about turning off wifi, downloading snake oil, and worshipping recycled NiCad batteries.
To make a long story short, the stock kernel (or perhaps the bootloader? That shouldn't be possible...) marks a few block devices as read-only if you're using a modified device. (If it's rooted, it's modified. If KNOX is tripped, it's modified, etc.) The kernel from Sammy is trying to flush caches to those devices (which is ironic when you consider they are marked read-only) before going into the suspend. The flush fails, so the entire suspend process fails. It seems that on the SGS6, there were only two devices like this. On the Note5, it seems to be 3 (everything except sda)
In that thread, @HomerSp not only tracked down the problem there, but also (thankfully) figured out that writes to a file in the /sys tree could work around the issue. Thankfully, because the entire point of THIS thread is to use the stock compiled kernel (with a modified ramdisk) to make life Happy. With 3 writes to the /sys tree, magically the device goes to sleep.
(Yes, I'll be taking care of it... and documenting it better...)
What a pain... for some reason, I couldn't write to the cache_type files from within the init.rc structure. No clue why not. Ended up having to add a "service" to the init structure
Anyway...
If you're following along at home, add the following lines to the bottom of init.rc:
Code:
service fix_cache_types /system/bin/sh /sbin/fix_cache_types.sh
class core
user root
oneshot
Then add a new file in the ramdisk's sbin directory called (I bet you guessed this already): fix_cache_types.sh
That file should have perms of 0750 and contain the following:
Code:
#!/system/bin/sh
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:1/cache_type
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:2/cache_type
echo 'temporary none' > /sys/class/scsi_disk/0:0:0:3/cache_type
If you're using the same kernel as I am (n920i), I've attached an updated image. Same rules, conditions, instructions as the last one I posted earlier in this thread. Except this one lets the device take naps. It helps the battery life.
Tomorrow (or Sunday) I'll see if this all works with xposed or not. (I seem to remember something about xposed not working with selinux enforcing kernels, but I could be wrong.) After that, if nothing prevents it (or me), I'll repackage this stuff again, and also throw together an n920c kernel (based on N920CXXU1AOH6) for general use.
BTW, at least on my n920i, I've confirmed that I don't reboot when getting a call (or making one), that NFC works, that bluetooth works, that I can wirelessly charge and quick charge. I'm trying to ensure all the "common" complaints with non-stock boot images are non-issues before giving this out... The whole purpose of using the stock kernel is to retain enforcing selinux and retain completely functional hardware.
garyd9 said:
yeah. well, at least assuming you know how to unpack and repack boot images... (Because this stuff is very experimental at this point, and still very much a work in progress, you should have a certain level of proficiency before mucking with it. I can't and won't hold anyone's hand for this stuff at this point.)
you need to unpack the boot image. Get the boot.img and unpack. Open the ramdisk. In the ramdisk is a file called 'sepolicy.'
Start with this post to figure out how to change it:
http://forum.xda-developers.com/showpost.php?p=63190351&postcount=2071
Find the reply to that post from Chainfire to see how it can be done without a "reference" device.
You'll also have to change the proper fstab as I documented already in this thread.
Then pack up the ramdisk and repack the boot image.
Click to expand...
Click to collapse
Hi
I have unpacked my boot.img. So I can see my sepolicy file in ramdisk/, I have patched it with my rooted Nubia Z9 but I don't understand next steps. Do you have time to explain a little more ?
For the fstab mods I have done it in fstab.samsungexynos7420 and fstab.samsungexynos7420.fwup. Is it ok ?
Thanks.
garyd9 said:
No support. No help. If you have to ask how to flash this or anything of the sort, this isn't for you.
Click to expand...
Click to collapse
garyd9 said:
I can't and won't hold anyone's hand for this stuff at this point.)
Click to expand...
Click to collapse
garyd9 said:
Same rules, conditions, instructions as the last one I posted earlier in this thread.
Click to expand...
Click to collapse
geek78 said:
Do you have time to explain a little more ?
Click to expand...
Click to collapse
Need I say more?
I might have found a quick and dirty Method to Port TWRP to the newest 7.2 shield experience. It's not guaranteed, but it's a chance im going to try. But as I didn't upgraded my own shield yet, I need some files from someone who has rooted his shield already.
1. Is an recovery.img
2. The build.prop
If I can get hands on these files I might be able to bring up a testing version asap
Enough. Seriously.....
Keep it clean, and on-topic... The rules are there for a reason. Don't remember them? HERE you go.
Adromir said:
I might have found a quick and dirty Method to Port TWRP to the newest 7.2 shield experience. It's not guaranteed, but it's a chance im going to try. But as I didn't upgraded my own shield yet, I need some files from someone who has rooted his shield already.
1. Is an recovery.img
2. The build.prop
If I can get hands on these files I might be able to bring up a testing version asap
Click to expand...
Click to collapse
If you want the files
Then can you please update your Sheild tv to the latest firmware for us 7.2.2
An back up the recovery.img
An back up your build.prob
Because I can't help you! I refuse!
Thx again have a great day
i hope you can port the twrp to nvidia sheild tv thx
Foster_e (Shield TV 2015 16GB) - 7.2.2 (30.7.130.7)
recovery.img + build.prop
https://drive.google.com/open?id=18E_u8as1E9dstmRtRwPb97hALdmsrdsc
The recovery is dumped directly from
Code:
/dev/block/platform/sdhci-tegra.3/by-name/SOS -> /dev/block/mmcblk0p16
No offense but quick and dirty does not do it on the new kernel.
You can port as much as you like and it might work for the older models but certainly not for the 2017 model.
And if you have no clue how to get the required files by simply exctracting the firmware files that you can download then I wonder how you will be able to actually modify the recovery image.
People with quite some experience tried and failed, so unless you compile TWRP from source he proper way it won't work (at least not on the 2017).
And even if compiled correctly there is no garantee it will be usable with the secure boot restrictions still in place.
You need a fully rooted device to fully use TWRP and you can not root the 7.2 in the simple way anymore.
Fully rooted the normal TWRP will work just fine.
Downunder35m said:
No offense but quick and dirty does not do it on the new kernel.
You can port as much as you like and it might work for the older models but certainly not for the 2017 model.
And if you have no clue how to get the required files by simply exctracting the firmware files that you can download then I wonder how you will be able to actually modify the recovery image.
People with quite some experience tried and failed, so unless you compile TWRP from source he proper way it won't work (at least not on the 2017).
And even if compiled correctly there is no garantee it will be usable with the secure boot restrictions still in place.
You need a fully rooted device to fully use TWRP and you can not root the 7.2 in the simple way anymore.
Fully rooted the normal TWRP will work just fine.
Click to expand...
Click to collapse
So if I understand you correctly the only way that a recent version of TWRP would work on 7.21 and above are if you have a "rooted" developer image? I have stayed with 7.1 (rooted with a flashed TWRP recovery) My expectation is that Ill stay with it until a stable version is released.
Odd thing is every OTA notification I get refuses to install. It just boots to TWRP without updating. I even opted in for the 7.2.2 beta updates and the shield refuses to update. Kinda thankful as others seem to have so many issues, just not worth it until 7.3 is released perhaps?
Any decent update is worth applying.
But if you ask if it is worth it for those really needing full root access then the answer is no.
The cummunity behind the shield might not be as big as behing Samsung devices but I am sure something will be figured out sooner or later.
@Downunder35m : As I mentioned in a deleted Post, I know how to get these Files from the recovery images. But they are Still 7.2.1 and as 7.2.2 already I didn't see a point in starting with already Outdated Files.
What kind of Things have you been trying already? My Approach was, that maybe TWRP hangs itself, because it can't find the Vendor and system Partition. After unpacking the recovery.img i found out, that the partitions still get mounted, but not over over the fstab anymore but single commands in some init scripts. So my Idea was to patch the kernel of the recovery image with a proper fstab and then use that to build a twrp around it, with the modified boot image. But sadly the resulting TWRP exceeded the Partitionsize. But i didn't set up the Source Tree to compile correctly, because I assumed that with such a breaking approach nvidia did at least moved onward to Android 8.1 ..
A real life job sadly limits my time far more than what I would like.
So maybe my failures are of use to you...
Lets start with the basics:
(All for the 2017 model!)
Firstly, the bootloader has changed and now enforces basically everything Google has on offer.
This means you can not just boot into a custom recovery because the bootloader does not accept it as genuine.
Lets say you get around this problem by, dor example, compiling TWRP from source and with the not yet realesed NVidia 7.2 sources.
There might be other ways but right now I think we can't get around compiling it from scratch.
Once you are able to somehow properly boot into TWRP there is more problems:
A lot if not all special rights and permissions are now handled almost exclusively by the DTB, or to be precise the DTS, which is compiled during boot.
By default TWRP does not make any use of the DTB but instead relies only on the FSTAB configuration.
And since TWRP is not an authorised service, task or app the bootloader won't provide the required rights.
The system partition stays invisible, the vendor part locked and since TWRP is required to copy or store at least some things somewhere this is detected as a possible intrusion.
As that the bootloader now marks the entire system as compromised - the dreaded corrupted system message appears and the system fails to boot.
You could tweak the init files, get the complete FSTAB info from the plat - and nonplat_file_contexts and even fiddle with the rest.
Then you get this happy feeling of a booting TWRP, pull a backup and think all is fine.
That it until you try to reboot and nothing works anymore.
The backup is useless as firstly you can not write it back and secondly it will be encrypted or otherwise corrupt.
To be able to use TWRP ADBD must be able to run in root mode, this is not possible by default on a user or release build, which NVidia now provides as a "developer" firmware.
A bootloader set to enforce all SeLinux and DM-Verity funtions will not allow any vital modifications to any vital part of the system.
In theory you must first at least free the bootloader (we can not do that) or destroy the safety, like by using a modified DTB.
Then you must make sure that you modifiy the prop files so full ADB and ADBD rights are available where they are needed.
After that TRWP will run just fine but it creates a cricle that first needs to be broken somehow
No root rights means no TWRP, no TWRP means no mods to the system.
Magisk currently fails to help us as it does not make use of DTB features at this stage.
And if you ask me then messing with the DTB can backfire badly.
Unlike normal firmwares we won't get a DTB partition included in the boot image or kernel image.
So once the dTB is stuffed too much it will be hard to impossible to install a genuine or custom firmware.
Once Pie comes out this will be worse.
Here the DTB too will be protected and generated/checked during boot.
Unless NVidia wakes up and removes these restrictions from the developer firmwares we will be locked out until someone finds a way to restore full root rights.
Right now I am hopin they will still release the full sources one day.
With a massive effors one could then just compile a normal userdebug firmware and all is fine once more.
Any luck yet? I upgraded one of my Shield TV to 7.2.2 from 7.2.1 dev root and want to install Magisk....
Thanks!
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
UPDATE: Boots but not working correctly so removed links
leezaal said:
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
https://www.androidfilehost.com/?fid=6006931924117905072
---------- Post added at 07:06 PM ---------- Previous post was at 07:05 PM ----------
Here you go TWRP recovery for Shield TV 2017 running 7.2.3
https://www.androidfilehost.com/?fid=6006931924117905072
Click to expand...
Click to collapse
Every time i open recovery it works, but after trying to reboot it bootloops at nvidia. I flash-all and it works again until i enter recovery (then botloops again on reboot). Am i missing something? (shield 2017 7.2.3 dev edition)
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1BCfXg9pUpFm_3sPXp_nEwBlkNU9nelkg/view?usp=sharing
rootfan said:
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1REnehReTaA5BamUBDe8XmBMyZG6zQkFB/view?usp=sharing
Click to expand...
Click to collapse
there is always the bug for 4k screen display?
rootfan said:
Here's twrp 3.3.1-0 for Shield TV. It seems to work properly on my shield pro running 7.2.3, I was able to flash magisk with it, but I don't have the 2017 model to test on. Please let me know how it works and report any errors in as detailed a manner as possible. As ever, this is experimental and you flash at your own risk :good:
https://drive.google.com/file/d/1REnehReTaA5BamUBDe8XmBMyZG6zQkFB/view?usp=sharing
Click to expand...
Click to collapse
Many thanks i renamed this to recovery.img and renamed magisk boot img to boot.img reflashed both as part of the whole 7.2.3 dev OS shield tv 2017 image.
booted into TWRP via adb from my pc it loads up fine on my LG 43" 4k tv no problem rebooted and got back into 7.2.3 also without any issues
UPDATE: TWRP will not let me wipe system / data or anything else or mount any partitions in order to wipe before trying to install anything making this sadly kinda useless right now
twrp seems complicated to be functional lately, the same on my mi max 3, but orange Fox might be better on Shield
leezaal said:
UPDATE: TWRP will not let me wipe system / data or anything else or mount any partitions in order to wipe before trying to install anything making this sadly kinda useless right now
Click to expand...
Click to collapse
Well that makes sense because I was overwriting the emmc fstab with the sata one. I've updated my original post with a link to a new twrp that should have this problem fixed. If you're still having issues please click on the menu button to the right of the home button in twrp and tell me what the log says. Do this when first booting into twrp before doing anything else. It should say something like the following with no mounting complaints if everything is working right.
Shield Debug: Hardware variant is darcy
Shield Debug: Using emmc fstab
Shield Debug: Found required fstab
rootfan said:
Well that makes sense because I was overwriting the emmc fstab with the sata one. I've updated my original post with a link to a new twrp that should have this problem fixed. If you're still having issues please click on the menu button to the right of the home button in twrp and tell me what the log says. Do this when first booting into twrp before doing anything else. It should say something like the following with no mounting complaints if everything is working right.
Shield Debug: Hardware variant is darcy
Shield Debug: Using emmc fstab
Shield Debug: Found required fstab
Click to expand...
Click to collapse
Thanks for the great feedback will DL the updated TWRP and give it a go will report back shortly
UPDATE: 100% working ! Amazing work all partitions mount etc no problem FULLY working TWRP on my 4k TV too
Compiled Stock Kernel + Sources
*insert usual disclaimer here*
I AM NOT RESPONSIBLE FOR ANY DAMAGE TO YOUR DEVICE. USE AT YOUR OWN RISK. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Testing? What will work?
Bugs:
- You tell me
INSTRUCTIONS
0. MAKE BACKUP
1. Download zip file
2. Download Magisk
3. Download Magisk fix
4. Flash Magisk
5. Flash Magisk fix
6. Flash Kernel zip
Resources:
SOURCE CODE
DOWNLOAD {Mod edit}
Credits:
karthick111
@datty
Hi mKenfenheuer, thanks for the credit.
I'm at the same point, I can get the kernel to build but no boot. I get dropped back to fastboot immediately after trying to boot.
I've tried flashing a blank vbmeta, but it didn't seem to help. I'm not sure if it is the AVB2.0 blocking the boot or something else.
I've noticed you've changed OPPO_TARGET_DEVICE to MSM_19061. How did you decide on that value? I've since been using MSM_19781 as that is the value of getprop ro.product.prjversion from my device (Malaysian version)
datty said:
Hi mKenfenheuer, thanks for the credit.
I'm at the same point, I can get the kernel to build but no boot. I get dropped back to fastboot immediately after trying to boot.
I've tried flashing a blank vbmeta, but it didn't seem to help. I'm not sure if it is the AVB2.0 blocking the boot or something else.
I've noticed you've changed OPPO_TARGET_DEVICE to MSM_19061. How did you decide on that value? I've since been using MSM_19781 as that is the value of getprop ro.product.prjversion from my device (Malaysian version)
Click to expand...
Click to collapse
Same behaviour for me. I've started with the target device mentioned in your repo, then changed to 19781, afterwards i've been trying out the ones from drivers/input/oppo_fp_driver/Makefile. I've just been stuck at 19061 since it was the last one i've tried, there is no specific reason for that.
I've not been working with devices with AVB 2.0 - i can see that my device is displaying "Secureboot enabled" in fastboot. As far as i can say this would be a pretty good reason for the device to refuse booting the new kernel as our kernel is probably not signed.
I'll look into signing the kernel with the dev key in the repo root. Maybe this helps. If not we would problaby need another solution to get around the secure boot.
I've made some progress, I can get the kernel to try to boot but I'm stuck at the realme logo without adb to debug what is wrong.
If you're using the kernel config extracted from the device, add the following config option.
CONFIG_BUILD_ARM64_DT_OVERLAY=y
I'm not sure if this is also necessary but I generated a new dtbo.img to flash from the compiled kernel.
You'll need mkdtboimg.py and you can run the following from the out/arch/arm64/boot directory after compilation.
python mkdtboimg.py create dtbo.img dts/*/*.dtbo
You can try to compare arter97 realme X kernel to raw source if it's any helpful.
datty said:
I've made some progress, I can get the kernel to try to boot but I'm stuck at the realme logo without adb to debug what is wrong.
If you're using the kernel config extracted from the device, add the following config option.
CONFIG_BUILD_ARM64_DT_OVERLAY=y
I'm not sure if this is also necessary but I generated a new dtbo.img to flash from the compiled kernel.
You'll need mkdtboimg.py and you can run the following from the out/arch/arm64/boot directory after compilation.
python mkdtboimg.py create dtbo.img dts/*/*.dtbo
Click to expand...
Click to collapse
Unfortunately i cannot. even with the config option i am still not able to get it booting.
I have created a repo to reflect how i am building the kernel and making the boot img + dtbo img.
https://github.com/mKenfenheuer/realme-X2Pro-kernel-build
Am i missing something? Also i assume that my generated dtbo.img is bad, as soon as i flash it, i cannot even boot to recovery.
This is a long shot but as @SHiFT! pointed out, maybe comparing the source of @arter97 can help us getthing this mess to boot.
mKenfenheuer said:
Unfortunately i cannot. even with the config option i am still not able to get it booting.
I have created a repo to reflect how i am building the kernel and making the boot img + dtbo img.
https://github.com/mKenfenheuer/realme-X2Pro-kernel-build
Am i missing something? Also i assume that my generated dtbo.img is bad, as soon as i flash it, i cannot even boot to recovery.
Click to expand...
Click to collapse
Try using the Image-dtb file rather than the plain Image to add to boot.img. You might need to change your make line to the following to get it to generate:
make -j$(nproc --all) O=out CC=clang CLANG_TRIPLE=aarch64-linux-gnu- Image-dtb dtbs
For the dtbo.img, it looks like you're adding *.dtb rather than *.dtbo.
I'll try and upload my build scripts later tonight, I'm at work at the minute and can't get to them.
I've made a little more progress, I've managed to get adb to come up at early boot so I can get a logcat and shell. The kernel looks to be failing on the audio and wireless at the minute from what I can see.
Thanks for the pointer to arter97's kernel. I can see where I've missed adding the external wifi module in, I'll give that a go and hopefully it gets a little further.
datty said:
Try using the Image-dtb file rather than the plain Image to add to boot.img. You might need to change your make line to the following to get it to generate:
make -j$(nproc --all) O=out CC=clang CLANG_TRIPLE=aarch64-linux-gnu- Image-dtb dtbs
For the dtbo.img, it looks like you're adding *.dtb rather than *.dtbo.
I'll try and upload my build scripts later tonight, I'm at work at the minute and can't get to them.
I've made a little more progress, I've managed to get adb to come up at early boot so I can get a logcat and shell. The kernel looks to be failing on the audio and wireless at the minute from what I can see.
Thanks for the pointer to arter97's kernel. I can see where I've missed adding the external wifi module in, I'll give that a go and hopefully it gets a little further.
Click to expand...
Click to collapse
My kernel is booting now, but wifi and aod are causing issues.
As for now, the zip requires magisk to be flashed first.
I've had some chat with other devs working on our devices kernel in the official telegram group, they're in touch with realme, realme will release their wifi driver from qualcomm soon on their github.
Credits for getting me up to here go to karthick111 from the telegram group.
Realme kernel source code got updated. Any great news?
BlazeMaster64 said:
Realme kernel source code got updated. Any great news?
Click to expand...
Click to collapse
No. I've imported the changes by realme, things got worse. Now the kernel is not booting anymore.
I'll look into this once i've got more time
mKenfenheuer said:
No. I've imported the changes by realme, things got worse. Now the kernel is not booting anymore.
I'll look into this once i've got more time
Click to expand...
Click to collapse
Do you think this phone is worth buying over xiaomi redmi k20 pro?
BlazeMaster64 said:
Do you think this phone is worth buying over xiaomi redmi k20 pro?
Click to expand...
Click to collapse
Of course it's a better phone in almost all terms
Great news! Turns out that the changes by realme actually fix the AoD and the reason why the kernel was not booting was my fault, i still had unfinished changes regarding SafetyNet which got compiled and caused the kernel to panic (i'd do that too if i were him).
So the current status is that now all main functionalities work as i was able to fix wifi too (with a little help of arter97).
All changes can be found in my github repo so feel free to fork!
mKenfenheuer said:
Great news! Turns out that the changes by realme actually fix the AoD and the reason why the kernel was not booting was my fault, i still had unfinished changes regarding SafetyNet which got compiled and caused the kernel to panic (i'd do that too if i were him).
So the current status is that now all main functionalities work as i was able to fix wifi too (with a little help of arter97).
All changes can be found in my github repo so feel free to fork!
Click to expand...
Click to collapse
Good job ,that's a good news Go on
If I may ask after you finish working in the kernel would it be easy to build custom roms with the help of your kernel ,Thanks to you
Hi. Thank you for your kernel. I'm a bit noob about kernel, so it's difficult to me understand kernel's features. What's this kernel different then the stock one?
asusgarb said:
Hi. Thank you for your kernel. I'm a bit noob about kernel, so it's difficult to me understand kernel's features. What's this kernel different then the stock one?
Click to expand...
Click to collapse
It's a work in progress to have a working kernel base for our phone which will then be useful for other people to build their own customized kernel with it.
Is the FP issue an kernel related issue? Or overlay?
natedogg20050 said:
Is the FP issue an kernel related issue? Or overlay?
Click to expand...
Click to collapse
What do you mean by FP issue? In case you are refering to the issues with GSI's, check out the issues on phhussons github:
https://github.com/phhusson/treble_experimentations/issues/1103
The cause of this is Realme/Oppo not sticking to standards and of course the fact that the in display fp reader is quite new and does not have any generic stock implementation yet.
So TL;DR its not a kernel issue. Phhusson is working on this with Google.
realme x2pro cm rom
---------- Post added at 12:22 PM ---------- Previous post was at 12:17 PM ----------
John Amin said:
Good job ,that's a good news Go on
If I may ask after you finish working in the kernel would it be easy to build custom roms with the help of your kernel ,Thanks to you
Click to expand...
Click to collapse
sir videos