Related
So, this deals with a post I already made here. I've tried patching the modem.bin file with the modem.img.p patch that came with the MDL update. When flashing the patched modem to the device, the baseband version still hasn't updated to MDL. crawrj mentioned that the MDM partition seems to have write protection on it, but I never got an error in heimdall saying that the partition couldn't be written to. In fact, the modem flashed just fine.
I've already got a custom kernel loaded, and KNOXAgent files removed, so I'd rather not have to downgrade to MDC in order to update to MDL. Also, patching the files went perfectly. No errors, and the file was the size that it was expected to be after patching. So, I'm not exactly sure what's going on with this.
This isn't the only file I would like to patch manually and update myself. I'm really questioning whether certain partitions on the device have write protection enabled for some reason, and how the write protection could be disabled so that the files can be flashed manually.
Anyone that could shed some light on this situation, it would be greatly appreciated. Thought about baking some ROMs, but it's impossible to have a custom kernel without having KNOXAgent removed or SEAndroid frozen. So being able to patch these files manually for future updates is a must.
Thanks in advance, guys.
RogueSly said:
So, this deals with a post I already made here. I've tried patching the modem.bin file with the modem.img.p patch that came with the MDL update. When flashing the patched modem to the device, the baseband version still hasn't updated to MDL. crawrj mentioned that the MDM partition seems to have write protection on it, but I never got an error in heimdall saying that the partition couldn't be written to. In fact, the modem flashed just fine.
I've already got a custom kernel loaded, and KNOXAgent files removed, so I'd rather not have to downgrade to MDC in order to update to MDL. Also, patching the files went perfectly. No errors, and the file was the size that it was expected to be after patching. So, I'm not exactly sure what's going on with this.
This isn't the only file I would like to patch manually and update myself. I'm really questioning whether certain partitions on the device have write protection enabled for some reason, and how the write protection could be disabled so that the files can be flashed manually.
Anyone that could shed some light on this situation, it would be greatly appreciated. Thought about baking some ROMs, but it's impossible to have a custom kernel without having KNOXAgent removed or SEAndroid frozen. So being able to patch these files manually for future updates is a must.
Thanks in advance, guys.
Click to expand...
Click to collapse
I've run into the same issue. Yes, there is some write protection in place.
What I've also tried so far is dumping the MDL mdm and NON_HLOS modem image files directly from an untouched unrooted MDL updated system (other than recovery) Then creating a tar.md5 file for use with Odin. This gave a secure check failed when trying to flash the modem.bin.
I also tried to use recovery to flash the files. No luck here either, it acts much like the low level HTC Radio_config Write protection in that it allows the flash, and even indicates that it was successful, but really it's just writing to a buffer and then checking it later (either on a reboot or whatever) and then since it fails some check, it discards it and uses the original partition.
I verified this by dd'ing the partition before and after the flash in the same recovery session. The partition does indeed change, but after the reboot, it reverts to the original image. Thus... no change.
I'm no expert on these, but from the way this seems, we need a way to install a modified bootloader or somehow set the "WRITE PROTECT: Enabled" to disabled on the bootloader/download screen to allow changes to certain partitions. (Modem and Non-HLOS being the only two that I think are the problem children right now)
What I haven't tried yet that COULD POSSIBLY work is adapting Dan's method of LOKI patching files and using a special command of aboot to flash them. (At least that's how it looks like it works based on a brief skim of the source code)
We'd have to figure out if our aboot is compatible with his method. We'd also need to find the location of the memory addresses and whatnot of where this special command exists in our aboot/memory.
But again, I don't know enough about it to make even an educated guess as to whether or not that would work at all...
Oh, and if Loki cannot be used for Modem patching/flashing, I'd bet the other variants of the device are also going to face the same problems as ours when trying to update modem/non-hlos partitions.
To add to the above post, I also tried using the apply_patch(...) bits from the OTA Update.zip's updater-script file and pulled the corresponding patch files and put them all into an update.zip to patch the partitions, which again said it was successful and of course reverted after rebooting.
Unknownforce said:
Oh, and if Loki cannot be used for Modem patching/flashing, I'd bet the other variants of the device are also going to face the same problems as ours when trying to update modem/non-hlos partitions.
To add to the above post, I also tried using the apply_patch(...) bits from the OTA Update.zip's updater-script file and pulled the corresponding patch files and put them all into an update.zip to patch the partitions, which again said it was successful and of course reverted after rebooting.
Click to expand...
Click to collapse
Ugh. Shoot me. -_-
I'll see if I can't try to figure out something on it. Probably spend some time on it tomorrow.
If anyone has anymore tips, that'd be awesome.
If it wasn't clear, it's not just the apnhlos/mdm partitions that are affected. The list of write-protected partitions during the MDL upgrade that I observe are:
mmcblk0p1: apnhlos
mmcblk0p2: mdm
mmcblk0p4: sbl2
mmcblk0p5: sbl3
mmcblk0p6: aboot
mmcblk0p7: rpm
mmcblk0p8: tz
Unknownforce said:
which again said it was successful and of course reverted after rebooting.
Click to expand...
Click to collapse
Just to make it clear to folks, the partition contents aren't reverting in a strict sense, the writes don't happen at all.
When write-protection is enabled, writes to the eMMC are silently dropped. Linux believes the writes are successful, and so keeps the updated contents in the page cache, which it then serves on subsequent read requests. Of course, when the device is rebooted, the contents of the page cache are lost.
This has been solved with Unknownforce's thread, found here.
Two again - MMB30K & MOB30O. I have no idea what the difference is, but I've used MOB30O successfully.
Link to the Nexus 6 OTA page with instructions for sideloading (no data loss, need to reinstall TWRP & reroot):
https://developers.google.com/android/nexus/ota
For those people who prefer to install separate components:
MMB30K
MOB30O
dahawthorne said:
Two again - MMB30K & MOB30O.
Click to expand...
Click to collapse
Did anyone ever figure out what the difference was? Google did this last time, and the result seemed the same between the two.
I went with MOB30M last time and it worked fine, so I'm going with MOB30O.
@dahawthorne added the links on the first post for you..
Thanks. I should have included the links, but I reckoned that anyone who's interested knows where to find them, and anyone who doesn't know probably shouldn't be tinkering...
But yes, the pointer is appreciated.
Edit: I used the OTA at this link - simpler, and doesn't lose your data:
https://developers.google.com/android/nexus/ota#shamu
Instructions are on the page. A simple sideload, flash recovery, install SuperSU.
Sir , is there any difference between MMB30K and MOB30O versions?
marcus droid said:
Sir , is there any difference between MMB30K and MOB30O versions?
Click to expand...
Click to collapse
we have to wait for the AOSP change logs on that
Encrytable boot/kernel IMGs:
MOB30O:
https://www.androidfilehost.com/?fid=24572369242688110
MMB30K:
https://www.androidfilehost.com/?fid=24572369242688111
What was the difference between the last 2 images? That was released without explanation as well!
I flashed the MOB30O version, anyone having trouble flashing SuperSU like me?
SuperSU flashed alright in TWRP(though the log seems a bit shorter than usual). When I rebooted the system, it says that SuperSU binary is not installed. I've tried to reflash TWRP (since stock recovery takes over) & different versions of SuperSU: 2.74 / 2.76 and can't seem to get root.
Strange. I sideloaded the MOB30O OTA, flashed TWRP (twice - it didn't stick first time) then installed SuperSU 2.76 from TWRP. No problems at all so far.
ayang02 said:
I flashed the MOB30O version, anyone having trouble flashing SuperSU like me?
SuperSU flashed alright in TWRP(though the log seems a bit shorter than usual). When I rebooted the system, it says that SuperSU binary is not installed. I've tried to reflash TWRP (since stock recovery takes over) & different versions of SuperSU: 2.74 / 2.76 and can't seem to get root.
Click to expand...
Click to collapse
I flashed SuperSU 2.76 just fine after flashing the MOB30O image. Also, I've never had stock recovery get replaced on my Nexus 6 ever. That's really strange.
The difference between these two images has been posted many times - not sure why people are confused about it!
MOB is the version you want.
MMB is the version for the Carriers who haven't approved the newer radio in MOB.
MOB also includes some kernel enhancements to increase performance. These changes related to the Kernel "Tick Rate". I think the changes have improved performance a little, but you're not going to think you've purchased a new phone or anything.
Summary:
MOB: Newer kernel with performance improvements, updated Radio image.
MMB: Older kernel sans performance improvements, old radio.
Summary: MOB is the train you want to be on.
ayang02 said:
I flashed the MOB30O version, anyone having trouble flashing SuperSU like me?
SuperSU flashed alright in TWRP(though the log seems a bit shorter than usual). When I rebooted the system, it says that SuperSU binary is not installed. I've tried to reflash TWRP (since stock recovery takes over) & different versions of SuperSU: 2.74 / 2.76 and can't seem to get root.
Click to expand...
Click to collapse
I dl'd the O image, extracted and flashed the system image only through twrp while at work. Rooted using a PC when I got home and I have no issues so fah. I use chainfires method and his method requires running his image with fast boot. Fastboot boot cf... What ever you have the file named. It'll do it's thing on the phone then reboot 1-3x before it boots up fully. This root it rebooted once. On previous updates, up to 3 times before it finally finished.
Why are people insisting on flashing the "old" modular way (extracting components for individual flashing) when Google have provided a total no-data-loss OTA? 15 minutes, risk-free. Why choose the difficult way when there's a seamless simple upgrade? Incomprehensible.
dahawthorne said:
Why are people insisting on flashing the "old" modular way (extracting components for individual flashing) when Google have provided a total no-data-loss OTA? 15 minutes, risk-free. Why choose the difficult way when there's a seamless simple upgrade? Incomprehensible.
Click to expand...
Click to collapse
For me it's because I've lost my data a couple of times in the past doing an OTA update. I guess old habits die hard and I like the control I have flashing each image file manually. At least that way I can be reasonably sure that my data isn't messed with by not flashing the userdata image, plus, I can skip flashing recovery so I don't have to reinstall that. It only took me 9 minutes to complete the process tonight, including re-rooting, doing it the "old" way.
dahawthorne said:
Why are people insisting on flashing the "old" modular way (extracting components for individual flashing) when Google have provided a total no-data-loss OTA? 15 minutes, risk-free. Why choose the difficult way when there's a seamless simple upgrade? Incomprehensible.
Click to expand...
Click to collapse
Two very simple reasons. 1) if you are rooted. 2) if you are unencrypted.
FWIW: it takes about 60 seconds to extract the images from the .zip file. And about 3 minutes to flash the boot and system image files in fastboot.
before i download the entire package can anyone tell me if there is a new modem in july update?
H4X0R46 said:
I flashed SuperSU 2.76 just fine after flashing the MOB30O image. Also, I've never had stock recovery get replaced on my Nexus 6 ever. That's really strange.
Click to expand...
Click to collapse
Then that means you were able to get root successfully. My TWRP recovery got overwritten because I didn't get root. Anyways, I am gonna try flashing stuff from scratch in a few days. I've also never had issues flashing monthly updates and SuperSU until now.
Sent from my Nexus 6 using XDA Free mobile app
adm1jtg said:
before i download the entire package can anyone tell me if there is a new modem in july update?
Click to expand...
Click to collapse
There is no new modem, nor bootloader. Just security updates to boot and system images.
I've been going through posts around here. I'm currently on OF1, but I see a ton of concerns on the OneClick method, reports of success being across the board. I'm confused on how we're not consistent on one method. But! That's my question - Which has most success / is most reliable? Opinions? I'd love direct links to the ones you prefer.
What bootstrap is current? I see TWRP is still on 4.3/4.4, and Safestrap apparently lost development? What are people using? I'm currently on 5.0 OF1 without root or bootstrap.
..And I saw something about unlocking the bootloader? The phone is recognized as a dev version afterword? Does this allow us to freely install whatever bootstrap we desire? I'd prefer to get TWRP if I can. I've got no fear of ODIN'ing the crap out of this thing.
I've seen comments all over the board on what ROMs work. Like, I can't seem to find much commonality from post to post. I'm a go-for-stable type of person. I adore stock, and don't need fluff. But the thing I do need ( If anyone can advise ) is to crack open this N900V to work on Straighttalk. This phone currently isn't active, and I've already got a Straight-talk SIM. Without any of this modding the SIM is "Unrecognized" per the phone, and I'm unable to change APN settings.
So if there are common setups to flash, I'd love a link to a Modem / GApps typically flashed if needed. Another love would be to get a CM13 (Or Any CM really, I saw CM11 for unlocked bootloader?) variant running, but again, opinions seem to be varied.
Any suggestions, opinions, directions, or guides welcome!
Thanks in advance.
alexmohr1990 said:
I've been going through posts around here. I'm currently on OF1, but I see a ton of concerns on the OneClick method, reports of success being across the board. I'm confused on how we're not consistent on one method. But! That's my question - Which has most success / is most reliable? Opinions? I'd love direct links to the ones you prefer.
What bootstrap is current? I see TWRP is still on 4.3/4.4, and Safestrap apparently lost development? What are people using? I'm currently on 5.0 OF1 without root or bootstrap.
..And I saw something about unlocking the bootloader? The phone is recognized as a dev version afterword? Does this allow us to freely install whatever bootstrap we desire? I'd prefer to get TWRP if I can. I've got no fear of ODIN'ing the crap out of this thing.
I've seen comments all over the board on what ROMs work. Like, I can't seem to find much commonality from post to post. I'm a go-for-stable type of person. I adore stock, and don't need fluff. But the thing I do need ( If anyone can advise ) is to crack open this N900V to work on Straighttalk. This phone currently isn't active, and I've already got a Straight-talk SIM. Without any of this modding the SIM is "Unrecognized" per the phone, and I'm unable to change APN settings.
So if there are common setups to flash, I'd love a link to a Modem / GApps typically flashed if needed. Another love would be to get a CM13 (Or Any CM really, I saw CM11 for unlocked bootloader?) variant running, but again, opinions seem to be varied.
Any suggestions, opinions, directions, or guides welcome!
Thanks in advance.
Click to expand...
Click to collapse
I will say in advance that this phone was my first time going thru any of this, so take what I have to say with a grain of salt if you would like. I have been rooted for about a week, unlocked bootloader and flashed Jasmine 6.1 rom yesterday.
I tried using this method of root for a few days with no results (http://forum.xda-developers.com/ver...b6-of1-n900v-note-3-verizon-oneclick-t3333569). I tried on multiple computers running Windows 7 x64 with no luck. It would start the process, but would never reboot my phone into download mode.
After failing at that, I ended up trying this method with both computers running Win 7 x64 (http://forum.xda-developers.com/verizon-galaxy-note-3/general/root-n900v-5-0-of1-one-click-t3330098) since there were multiple posts saying that it worked for them using Win 7 and running as admin. It would reboot my phone and then the computer program would freeze before the phone would start to download. I ended up taking the free Win 10 update on the wife's laptop and tried again. Phone was rooted in about 90 seconds. All I did was download KEIS and install the drivers it had, then try the program again. Worked flawlessly.
I followed this (http://forum.xda-developers.com/ver.../how-to-unlock-verizon-galaxy-note-3-t3360309) to unlock my bootloader. The one exception, is that I followed a YouTube video on how to do it by using a Terminal Emulator on the phone rather than via PC. In the video the guy adds "samsung" to a couple places in the code, but I did not. I followed the code exactly as is in the post I linked and it worked.
To install TWRP via FlashFire, you have to unlock bootloader. Once you unlock the bootloader, FlashFire will give you an option to download and flash TWRP.
Poor Man's App Freeze
@RaaidR
FWIW, you can also perform a similar "freezing" function by going in to the /system/app folder and doing a
chmod 0000 filename.apk
On the .apk and .odex files you want to freeze. (For all I know that might be the technique that TiBu uses)
Note that since /system is typically mounted read-only, you have to temporarily mount it read-write when doing this. For example, in a terminal emulator:
Code:
su
mount -o remount,rw /system
cd /system/app
chmod 0000 Knox*.apk Knox*.odex
...
cd /
sync
mount -o remount,ro /system
exit
exit
Unless you need to make room inside of /system/app to install other apps (which will then survive a recovery-boot "factory reset"*), there's almost nothing to be gained by actually removing them rather than freezing them. They don't consume any runtime resources and probably don't even affect boot time following a cache/dalvik-cache wipe once they are "frozen".
Here is a list of things I froze in an older stock ROM; mostly to prevent OTA nagging, Knox BS, and some VZW spyware:
ContainerAgent.apk
ContainerAgent.odex
ContainerEventsRelayManager.apk
ContainerEventsRelayManager.odex
FWUpgrade.apk
FWUpgrade.odex
KLMSAgent.apk
KLMSAgent.odex
KNOXAgent.apk
KNOXAgent.odex
KNOXStore.apk
KNOXStore.odex
KnoxAttestationAgent.apk
KnoxAttestationAgent.odex
LocalFOTA.apk
SDM.apk
SDM.odex
VMS.apk
This post (from 4.3) has a more extensive list of debloating; I haven't used it so I can't vouch for it.
*some market apps don't seem to behave correctly when you drop their .apk into /system/app, so ymmv on this style of hack.
@alexmohr1990
Sorry for the small tangent/thread-jack.
If you like solid, bugfree performance, stick with rooted stock (but kill off stuff you dont want to be running via freezing and Android's built in app "Disable" feature in Settings==>Application manager)
Frankly, the only things you need to "freeze" are apps that do not appear in the Application manager - e.g. stuff like Verizon spyware (VMS.apk) and Knox crapola. For anything that shows up in the App manager, you can use the "Disable" feature. (TiBu "freezing" pre-dates
the appearance of the app Disable feature in Stock Android, so a lot of long time users of TiBu don't seem to be aware of Android's now built in app disable feature)
Can't help with the carrier stuff; I've only been on Verizon.
good luck
bftb0 said:
@RaaidR
FWIW, you can also perform a similar "freezing" function by going in to the /system/app folder and doing a
chmod 0000 filename.apk
On the .apk and .odex files you want to freeze. (For all I know that might be the technique that TiBu uses)
Note that since /system is typically mounted read-only, you have to temporarily mount it read-write when doing this. For example, in a terminal emulator:
Code:
su
mount -o remount,rw /system
cd /system/app
chmod 0000 Knox*.apk Knox*.odex
...
cd /
sync
mount -o remount,ro /system
exit
exit
Unless you need to make room inside of /system/app to install other apps (which will then survive a recovery-boot "factory reset"*), there's almost nothing to be gained by actually removing them rather than freezing them. They don't consume any runtime resources and probably don't even affect boot time following a cache/dalvik-cache wipe once they are "frozen".
Here is a list of things I froze in an older stock ROM; mostly to prevent OTA nagging, Knox BS, and some VZW spyware:
ContainerAgent.apk
ContainerAgent.odex
ContainerEventsRelayManager.apk
ContainerEventsRelayManager.odex
FWUpgrade.apk
FWUpgrade.odex
KLMSAgent.apk
KLMSAgent.odex
KNOXAgent.apk
KNOXAgent.odex
KNOXStore.apk
KNOXStore.odex
KnoxAttestationAgent.apk
KnoxAttestationAgent.odex
LocalFOTA.apk
SDM.apk
SDM.odex
VMS.apk
This post (from 4.3) has a more extensive list of debloating; I haven't used it so I can't vouch for it.
*some market apps don't seem to behave correctly when you drop their .apk into /system/app, so ymmv on this style of hack.
@alexmohr1990
Sorry for the small tangent/thread-jack.
If you like solid, bugfree performance, stick with rooted stock (but kill off stuff you dont want to be running via freezing and Android's built in app "Disable" feature in Settings==>Application manager)
Frankly, the only things you need to "freeze" are apps that do not appear in the Application manager - e.g. stuff like Verizon spyware (VMS.apk) and Knox crapola.
Can't help with the carrier stuff; I've only been on Verizon.
good luck
Click to expand...
Click to collapse
I went with Jasmine 6.1 so that I could use the Xposed software since it requires a deodexed rom.........stock rom isn't deodexed from what I read.
Also, I read a few list's like that, but wasn't sure on how much I could screw up in 5.0 since the list's were from previous versions of Android.
@RaaidR : This is the type of post I'm looking for. I've been ROMing since a Droid 2, but never hadid as much trouble as this silly vzw version note. Thanks!
@bftb0 Well. Typically I would stay stock. But even stock has anyone crafted an unofficial stock higher than 5.0? I saw something about s7 firmware. I did recently install CM13 for a friend on a S4. Made me super jelly and wanted to try it. My biggest concern is getting this thing unlocked to the point I can use preferably LTE on straighttalk. So I definitely need to be able to modify apn settings, but unlocking is a point I've never dived into, much less on such a difficult model.
alexmohr1990 said:
@RaaidR : This is the type of post I'm looking for. I've been ROMing since a Droid 2, but never hadid as much trouble as this silly vzw version note. Thanks!
@bftb0 Well. Typically I would stay stock. But even stock has anyone crafted an unofficial stock higher than 5.0? I saw something about s7 firmware. I did recently install CM13 for a friend on a S4. Made me super jelly and wanted to try it. My biggest concern is getting this thing unlocked to the point I can use preferably LTE on straighttalk. So I definitely need to be able to modify apn settings, but unlocking is a point I've never dived into, much less on such a difficult model.
Click to expand...
Click to collapse
You are welcome. If you run across any issues, I might be able to help, but my knowledge is limited. Good luck going forward, let me know how it works out for you.
Excellent! @RaaidR all of it for the most part worked like a charm. Root was no trouble, same for bootloader. Both on first try. Had to flash TWRP Manually through Odin, but I got it. Good stuff. Now to hunt down a ROM. Thanks a ton for such a precise response!
So... For ROMs... Does this mean I can now access Developer Version ROMs? I'm looking for something unlocked (Or can easily modify carrier settings) and stable. Not into the idea of "Whelp. Guess it decided not to boot today" that I've run into with ROMing on previous phones. Haven't really got to play with Xposed yet, so it'd be cool to tool around with it too.
Jasmine 6.1 comes with Xposed infused and is very close to stock rom from what I have experienced so far and from what others have said about it. As far as Developer Roms go, that I can't tell you much about that. I went straight to Jasmine because from everything I have read it seems to be the most stable of what is out there. Hopefully somebody on here can give you some different options. If you decide to go with Jasmine, make sure to remember to flash the partial firmware thru Odin after flashing the rom.
Is this the Jasmine ROM you refer to? http://forum.xda-developers.com/showthread.php?t=2760380
Guess I've never had a device with an unlocked bootloader. Hah. I guess my next question would be - I wouldn't be able to use any Pre-5.0 ROMs? Not that I truthfully want to for the most part. But as you said, there just seems to be a slim amount of things about as I guess many have moved on to newer devices and Root/Bootloader progress came so late.
I'll give it a try though. Plan to make a day of flashing.
Edit: For Jasmine... It makes note of a retail version and developer version... Are we technically on the dev version after the unlock? I didn't see a mention to tell the difference.
I believe you are not able to downgrade from 5.0 once you go to it, or at least that was my understand pre-root. If that has changed post-root, I cannot say but I didn't attempt it.
Also, although we now have the developer mode enabled due to unlocking bootloader, I didn't know the difference and chose to follow the retail instructions and it worked flawlessly.
I searched for "Jasmine 6.1 install" on YouTube and followed the video by EverythingSamsungPro since I also followed his video on bootloader unlock.
alexmohr1990 said:
Edit: For Jasmine... It makes note of a retail version and developer version... Are we technically on the dev version after the unlock? I didn't see a mention to tell the difference.
Click to expand...
Click to collapse
unlocked bootloader == developer edition.
Having a "DevEd" device means that the bootloader will no long prevent you from booting unsigned "bootable" partitions (boot and recovery). And, also that Odin no longer requires things flashed in the AP slot such as boot.img, recovery.img, and system.img to be Samsung signed.
The implications is that the "Retail" version of Jasmine is required to use the pure stock boot image, and no custom recovery, whereas the DevEd version can do one or both. Small mods of the boot.img blob are the most likely.
Noting that the "boot.img" binary blob is actually three separate pieces:
boot.img = kernel + ramdisk + devicetree
I can't tell you if the DevEd version of Jasmine modifies the stock kernel, the ramdisk, or the device treee (or any combination thereof). Intuition tells me that mods of the devicetree are highly unlikely and small mods of the ramdisk are the most likely. Is the kernel modded? I don't know, you'll have to dig into that thread to find out.
Practically speaking, having only a single boot which is rooted is a bit of a hazard, but it is far more of a hazard if the bootloader is still locked. If that one boot/ROM started boot-looping after a broken modification by the owner, the only recourse is to go back to pure stock using Odin and start re-rooting. With an unlocked bootloader, in principle you could install a custom recovery (flashing it with Odin) at any time, so a 2nd independent, rooted custom boot/recovery is available to perform system maintenance.
So you can use either the DevEd version or the Retail version on an unlocked phone. Probably you should dig in to the Jasmine thread to find out if the differences between the two are compelling to you based on whatever it is you want your phone to do.
good luck
PS. See this very nearly identical inquiry & reply in the Q&A Forum, especially the remarks about "partial firmware flashing". You do not want to over-flash your unlocked bootloader.
---------- Post added at 11:23 PM ---------- Previous post was at 11:08 PM ----------
RaaidR said:
I believe you are not able to downgrade from 5.0 once you go to it, or at least that was my understand pre-root. If that has changed post-root, I cannot say but I didn't attempt it.
Click to expand...
Click to collapse
What is known for sure is that the Samsung bootloader (which is actually a whole slew of partitions) enforces an Anti-Rollback policy on the bootloader firmware.
It is actually not known if it would be possible to run a 4.3.x or 4.4.x stock ROM on later versions of bootloader firmware. For instance, if your bootloader firmware was OB6 or OF1 ("5.x") but you flashed stock versions of NC4/NK1 ROM software (4.4.x "boot.img" and "system.img")
Why is it not known? Because AFAIK, no-one has tried it. (Well, actually @ryanbg tried all sorts of dangerous flashing combinations in the old days, but I'm not sure if he published the details). I suspect it would be safe to try these experiments (clean flash of only boot.img and system.img from prior releases) - if and only if you have an unlocked bootloader. (If they don't work, flash something that does; hard to imagine they will cause a hard-bricking on what is a DevEd phone).
So it is probably most accurate to say "we can't flash OB6 or OF1 bootloader firmware back to NC4", but "it's not known if OB6/OF1 bootloader would successfully boot 4.4.x (or even 4.3.x) ROMs" (boot.img + system.img)
I hope that's not too confusing. It's a little subtle, but makes far more sense to anyone who realizes that there are a ton of partitions in these Samsung phones, and that "4.3", "4.4", "5.0" are more closely associated with boot.img and system.img than they are with the (many) bootloader partitions.
You can get CM13 here: http://forum.xda-developers.com/ver...opment/rom-temaseks-unofficial-build-t3364382
I've been running it for a couple of weeks and I have found it to be the only usable MM rom at the moment. Otherwise that Jasmine ROM is a solid choice.
bftb0 said:
unlocked bootloader == developer edition.
Having a "DevEd" device means that the bootloader will no long prevent you from booting unsigned "bootable" partitions (boot and recovery). And, also that Odin no longer requires things flashed in the AP slot such as boot.img, recovery.img, and system.img to be Samsung signed.
The implications is that the "Retail" version of Jasmine is required to use the pure stock boot image, and no custom recovery, whereas the DevEd version can do one or both. Small mods of the boot.img blob are the most likely.
Noting that the "boot.img" binary blob is actually three separate pieces:
boot.img = kernel + ramdisk + devicetree
I can't tell you if the DevEd version of Jasmine modifies the stock kernel, the ramdisk, or the device treee (or any combination thereof). Intuition tells me that mods of the devicetree are highly unlikely and small mods of the ramdisk are the most likely. Is the kernel modded? I don't know, you'll have to dig into that thread to find out.
Practically speaking, having only a single boot which is rooted is a bit of a hazard, but it is far more of a hazard if the bootloader is still locked. If that one boot/ROM started boot-looping after a broken modification by the owner, the only recourse is to go back to pure stock using Odin and start re-rooting. With an unlocked bootloader, in principle you could install a custom recovery (flashing it with Odin) at any time, so a 2nd independent, rooted custom boot/recovery is available to perform system maintenance.
So you can use either the DevEd version or the Retail version on an unlocked phone. Probably you should dig in to the Jasmine thread to find out if the differences between the two are compelling to you based on whatever it is you want your phone to do.
good luck
PS. See this very nearly identical inquiry & reply in the Q&A Forum, especially the remarks about "partial firmware flashing". You do not want to over-flash your unlocked bootloader.
---------- Post added at 11:23 PM ---------- Previous post was at 11:08 PM ----------
What is known for sure is that the Samsung bootloader (which is actually a whole slew of partitions) enforces an Anti-Rollback policy on the bootloader firmware.
It is actually not known if it would be possible to run a 4.3.x or 4.4.x stock ROM on later versions of bootloader firmware. For instance, if your bootloader firmware was OB6 or OF1 ("5.x") but you flashed stock versions of NC4/NK1 ROM software (4.4.x "boot.img" and "system.img")
Why is it not known? Because AFAIK, no-one has tried it. (Well, actually @ryanbg tried all sorts of dangerous flashing combinations in the old days, but I'm not sure if he published the details). I suspect it would be safe to try these experiments (clean flash of only boot.img and system.img from prior releases) - if and only if you have an unlocked bootloader. (If they don't work, flash something that does; hard to imagine they will cause a hard-bricking on what is a DevEd phone).
So it is probably most accurate to say "we can't flash OB6 or OF1 bootloader firmware back to NC4", but "it's not known if OB6/OF1 bootloader would successfully boot 4.4.x (or even 4.3.x) ROMs" (boot.img + system.img)
I hope that's not too confusing. It's a little subtle, but makes far more sense to anyone who realizes that there are a ton of partitions in these Samsung phones, and that "4.3", "4.4", "5.0" are more closely associated with boot.img and system.img than they are with the (many) bootloader partitions.
Click to expand...
Click to collapse
I did flash the partial firmware on mine and did not flash the modem part for the developer edition, so far I have had no issues. Am I missing something I am supposed to have?
RaaidR said:
I did flash the partial firmware on mine and did not flash the modem part for the developer edition, so far I have had no issues. Am I missing something I am supposed to have?
Click to expand...
Click to collapse
Well, the point of that partial firmware was to upgrade the bootloader firmware set (if needed) and also install a stock boot and recovery images. Here's the contents of that .tar.md5.7z archive:
Code:
-rw-r--r-- hsbadr/staff 5932800 2015-07-16 06:39 NON-HLOS.bin
-rw-r--r-- hsbadr/staff 1110652 2015-07-16 06:39 [b][color=red]aboot.mbn[/color][/b]
-rw-r--r-- hsbadr/staff 10840336 2015-07-16 06:39 [b]boot.img[/b]
-rw-r--r-- hsbadr/staff 56542976 2015-07-16 06:36 modem.bin
-rw-r--r-- hsbadr/staff 11796752 2015-07-16 06:39 [b]recovery.img[/b]
-rw-r--r-- hsbadr/staff 164388 2015-07-16 06:39 rpm.mbn
-rw-r--r-- hsbadr/staff 280976 2015-07-16 06:38 sbl1.mbn
-rw-r--r-- hsbadr/staff 32356 2015-07-16 06:38 sdi.mbn
-rw-r--r-- hsbadr/staff 321284 2015-07-16 06:38 tz.mbn
The one shown in red - "aboot.mbn" is the final (third) stage of the bootloader, and it corresponds to the "aboot" partition which is modified by the bootloader unlock technique. "aboot.mbn" is the code you visually observe running on the phone in Odin mode and during bootloader sequences.
So, what you did was that you re-locked your bootloader, and if you had a custom recovery installed you overwrote that with the stock version. If you were to boot into Odin mode, you will no longer see the "MODE: DEVELOPER" message.
If you want to unlock the bootloader, just run the unlock tool again as root. (You will have to destroy your external SD card again)
Good luck
PS. This is a little of a tangent but it is worthwhile that you look at that file listing above as you are new to this. Whenever a (Note 3) "bootloader" firmware upgrade is performed in Odin, all of the following files are flashed in the same Odin session:
NON-HLOS.bin, aboot.mbn, modem.bin, rpm.mbn, sbl1.mbn, sdi.mbn, tz.mbn
These files each are flashed into separate partitions, but they have interlocking dependencies; you can't flash them individually in a willy-nilly fashion. If you ever do that you are risking a hard-bricking.
The only exception in this group is the "modem.bin" radio firmware. (Some people fool around (mix-n-match) with various radio firmwares, probably without any firm evidence to support their claims as to why they engage in such behavior.)
When people distinguish between "ROM" and "bootloader firmware", they mean by ROM these files:
recovery.img (stock ROMs; omitted if you already have a custom recovery)
boot.img
system.img.ext4
cache.img.ext4
That's what made the bundle you flashed "partial" - it didn't contain the stock system.img or cache.img
bftb0 said:
Well, the point of that partial firmware was to upgrade the bootloader firmware set (if needed) and also install a stock boot and recovery images. Here's the contents of that .tar.md5.7z archive:
Code:
-rw-r--r-- hsbadr/staff 5932800 2015-07-16 06:39 NON-HLOS.bin
-rw-r--r-- hsbadr/staff 1110652 2015-07-16 06:39 [b][color=red]aboot.mbn[/color][/b]
-rw-r--r-- hsbadr/staff 10840336 2015-07-16 06:39 [b]boot.img[/b]
-rw-r--r-- hsbadr/staff 56542976 2015-07-16 06:36 modem.bin
-rw-r--r-- hsbadr/staff 11796752 2015-07-16 06:39 [b]recovery.img[/b]
-rw-r--r-- hsbadr/staff 164388 2015-07-16 06:39 rpm.mbn
-rw-r--r-- hsbadr/staff 280976 2015-07-16 06:38 sbl1.mbn
-rw-r--r-- hsbadr/staff 32356 2015-07-16 06:38 sdi.mbn
-rw-r--r-- hsbadr/staff 321284 2015-07-16 06:38 tz.mbn
The one shown in red - "aboot.mbn" is the final (third) stage of the bootloader, and it corresponds to the "aboot" partition which is modified by the bootloader unlock technique. "aboot.mbn" is the code you visually observe running on the phone in Odin mode and during bootloader sequences.
So, what you did was that you re-locked your bootloader, and if you had a custom recovery installed you overwrote that with the stock version. If you were to boot into Odin mode, you will no longer see the "MODE: DEVELOPER" message.
If you want to unlock the bootloader, just run the unlock tool again as root. (You will have to destroy your external SD card again)
Good luck
PS. This is a little of a tangent but it is worthwhile that you look at that file listing above as you are new to this. Whenever a (Note 3) "bootloader" firmware upgrade is performed in Odin, all of the following files are flashed in the same Odin session:
NON-HLOS.bin, aboot.mbn, modem.bin, rpm.mbn, sbl1.mbn, sdi.mbn, tz.mbn
These files each are flashed into separate partitions, but they have interlocking dependencies; you can't flash them individually in a willy-nilly fashion. If you ever do that you are risking a hard-bricking.
The only exception in this group is the "modem.bin" radio firmware. (Some people fool around (mix-n-match) with various radio firmwares, probably without any firm evidence to support their claims as to why they engage in such behavior.)
When people distinguish between "ROM" and "bootloader firmware", they mean by ROM these files:
recovery.img (stock ROMs; omitted if you already have a custom recovery)
boot.img
system.img.ext4
cache.img.ext4
That's what made the bundle you flashed "partial" - it didn't contain the stock system.img or cache.img
Click to expand...
Click to collapse
In the download screen I still show as being in developer mode, but I did unlock the bootloader before flashing Jasmine ROM. So would flashing the partial firmware be the reason why I had to reflash TWRP with FlashFire after flashing Jasmine?
RaaidR said:
In the download screen I still show as being in developer mode, but I did unlock the bootloader before flashing Jasmine ROM. So would flashing the partial firmware be the reason why I had to reflash TWRP with FlashFire after flashing Jasmine?
Click to expand...
Click to collapse
For sure, yes. (cause of recovery needing to be re-flashed).
But that is really very surprising that you still have Developer Mode showing. I guess I'll look into something (perhaps the DE sig is flashed into the back end of the aboot partition and it survived the new flash because the aboot.mbn image is not sufficiently large to cause an erasure of the erase block that the sig lives in.)
That's new information you just discovered right there.
I assume that you do not get the "Unauthorized Software" pop-up message when you boot the custom recovery, is that right?
Thanks for the information.
bftb0 said:
For sure, yes. (cause of recovery needing to be re-flashed).
But that is really very surprising that you still have Developer Mode showing. I guess I'll look into something (perhaps the DE sig is flashed into the back end of the aboot partition and it survived the new flash because the aboot.mbn image is not sufficiently large to cause an erasure of the erase block that the sig lives in.)
That's new information you just discovered right there.
I assume that you do not get the "Unauthorized Software" pop-up message when you boot the custom recovery, is that right?
Thanks for the information.
Click to expand...
Click to collapse
Nope, I don't get any warnings or pop-ups about anything when I load TWRP. When I boot to TWRP, it just boots right to it like it should without any warnings at all.
Just so you know, this is exactly what I did in order:
Rooted phone (Yemen n900v 5.0 of1 one click)
Unlocked bootloader with Terminal Emulator
Downloaded FlashFire and flashed TWRP
Flashed Jasmine 6.1 ROM with FlashFire (in FlashFire I selected Wipe and chose System Data, 3rd Party Apps, Dalvik cache) and set reboot in FlashFire to Bootloader
Flashed partial firmware via ODIN in AP slot
During reboot, I removed battery and booted into Recovery Mode (Vol Up, Home, Power Button)
Wipe/Factory Reset
Wipe Cache Partition
Reboot and complete setup
After this I re-downloaded all of them and restored data via TB. During this, I noticed that I no longer had TWRP. Opened FlashFire again and downloaded and flashed TWRP one more time.
Being new to all of this, I assumed that TWRP got wiped when I flashed new ROM and did all of the wipes so I just assumed that it wiped everything else also. After this, everything works perfectly. I don't have any issues with anything, except I wish I could download some new themes to use with the ROM (may be able to, I just haven't found out how to yet. I have been looking, just haven't come across the correct stuff to read).
As far as it being new information, leave it up to the noob to stumble across it haha.
RaaidR said:
Being new to all of this, I assumed that TWRP got wiped when I flashed new ROM and did all of the wipes so I just assumed that it wiped everything else also.
Click to expand...
Click to collapse
Shouldn't be "the ROM" that did that. Devs can do whatever they want, but it has been the custom for ROM devs to avoid packaging up recovery images for flashing during a ROM install. First because (strictly speaking) it's not needed by "the ROM" to function, and second because many devices have more than one choice for custom recoveries, so doing that would be over-riding the owners' decisions about what custom recovery to use.
In this case though, the dual- or triple- purpose Jasmine ROM (DevEd/Retail/Multiboot) has to install a stock boot image for Retail versions. In most stock distributions, the device or carrier vendor uses the identical kernel in the "boot.img" file that is used in the "recovery.img" file. (The ramdisks are different, and that accounts for their wildly different behaviors - the recovery doesn't need to rely on /system or /data to boot up to a primitive UI such as TWRP... and that's exactly why recoveries are used for OTA installations, upgrades and repairs - neither /system nor /data need to be mounted for them to boot up a UI; in a way of speaking, those file systems are "offline" when the recovery is booted. That of course makes manipulating them, erasing them, etc much more convenient).
I haven't followed the Jasmine thread much, but since there have been version releases which are based off of different stock releases, hsbadr needs to insure that the correct stock boot partition (file "boot.img") is installed along with the customized stock ROM (Jasmine) for the Retail version, and that's the purpose of that "partial firmware" flash. I suppose he left the recovery.img in there simply because it is good practice to keep stock recovery images in lockstep with stock boot images. And of course, that development predates the appearance of "Unlocked" bootloaders, so there was no reason on Retail devices to have anything except a stock recovery installed.
.
bftb0 said:
Shouldn't be "the ROM" that did that. Devs can do whatever they want, but it has been the custom for ROM devs to avoid packaging up recovery images for flashing during a ROM install. First because (strictly speaking) it's not needed by "the ROM" to function, and second because many devices have more than one choice for custom recoveries, so doing that would be over-riding the owners' decisions about what custom recovery to use.
In this case though, the dual- or triple- purpose Jasmine ROM (DevEd/Retail/Multiboot) has to install a stock boot image for Retail versions. In most stock distributions, the device or carrier vendor uses the identical kernel in the "boot.img" file that is used in the "recovery.img" file. (The ramdisks are different, and that accounts for their wildly different behaviors - the recovery doesn't need to rely on /system or /data to boot up to a primitive UI such as TWRP... and that's exactly why recoveries are used for OTA installations, upgrades and repairs - neither /system nor /data need to be mounted for them to boot up a UI; in a way of speaking, those file systems are "offline" when the recovery is booted. That of course makes manipulating them, erasing them, etc much more convenient).
I haven't followed the Jasmine thread much, but since there have been version releases which are based off of different stock releases, hsbadr needs to insure that the correct stock boot partition (file "boot.img") is installed along with the customized stock ROM (Jasmine) for the Retail version, and that's the purpose of that "partial firmware" flash. I suppose he left the recovery.img in there simply because it is good practice to keep stock recovery images in lockstep with stock boot images. And of course, that development predates the appearance of "Unlocked" bootloaders, so there was no reason on Retail devices to have anything except a stock recovery installed.
.
Click to expand...
Click to collapse
Ah, I gotcha. Yea, I just guessed that since I did all those wipes that was cause for it having disappeared rather than me flashing that firmware, which makes more sense. Is there "Dev" or "Retail" version of Jasmine or is it just the install process that changes depending on whether your phone is developer or retail?
RaaidR said:
Ah, I gotcha. Yea, I just guessed that since I did all those wipes that was cause for it having disappeared rather than me flashing that firmware, which makes more sense. Is there "Dev" or "Retail" version of Jasmine or is it just the install process that changes depending on whether your phone is developer or retail?
Click to expand...
Click to collapse
TBH I don't know. I'd say "read the thread" but it's what - 1200+ pages long?
Maybe search that thread for keywords.
One way to determine it would be two download the installation bundles for each and pick them apart or perform checksums e.g. on the boot.img file from each. If they have identical checksums (MD5 or SHA1 or whatever), then the kernel+ramdisk (== boot image) are the same. The same can be done for any pair of files to test for "sameness". If the checksums are different, then you have to pick them apart more carefully to find out what the differences are.
The boot image controls many long lived "services" that get started by the parent of all processes in Unix/Linux - the "init" process. So many times even stock-derived boot images have tweaks in their ramdisk (which contain files such as the "init.*.rc" files that control how init behaves), even if a pure stock kernel is used. But I don't know if the DevEd version of Jasmine has mods like that; it well might though.
Hi all, I posted this in the 6P bootloop thread, but didn't get a response. As that is a pretty LONG thread, i'm thinking my question may have gotten lost in the jumble.
Quick run down.
A few months back my 6P started the BLOD. I found the fix listed on these pages, applied it, and have been happily using my phone ever since. Phone is bone stock 7.1.2 other than the TWRP recovery and the modified EX kernel for 4 cores.
Since the fix, my phone FINALLY got the OTA update to go to Android 8.0 and i obviously want to get it done. My concern is HOW to do this without causing more headache.
Can anyone point me in the right direction? Should i use the OTA update or download the factory image from Google?
I've got some knowledge as i used to be into the "rooting" scene back in the day, but haven't for a while, so i feel a little lost.
Thanks for any help.
johnnyphive said:
Hi all, I posted this in the 6P bootloop thread, but didn't get a response. As that is a pretty LONG thread, i'm thinking my question may have gotten lost in the jumble.
Quick run down.
A few months back my 6P started the BLOD. I found the fix listed on these pages, applied it, and have been happily using my phone ever since. Phone is bone stock 7.1.2 other than the TWRP recovery and the modified EX kernel for 4 cores.
Since the fix, my phone FINALLY got the OTA update to go to Android 8.0 and i obviously want to get it done. My concern is HOW to do this without causing more headache.
Can anyone point me in the right direction? Should i use the OTA update or download the factory image from Google?
I've got some knowledge as i used to be into the "rooting" scene back in the day, but haven't for a while, so i feel a little lost.
Thanks for any help.
Click to expand...
Click to collapse
Well, for starters do NOT take the OTA. It will either fail or boot loop your phone. Due to the fact you have a modified boot.img you will need to update manually using fastboot with the full image. Re-apply the modified kernel after you finish updating the partitions, but BEFORE booting the first time. You can follow most guides on how to manually update a full image using fastboot, just add the step of flashing the modified kernel before booting.
Thanks for the reply and the help. If i could ask for a little more help, as this is my only phone.
Can you explain the difference between the modified boot.img and the modified kernel?
If i download the factory image from here (https://developers.google.com/android/images) is it ok to the get the latested one (Nov 2017) or do i need to get the original one (Sep 2017 as i'm on Fi)
Once i flash the factory image, is it going to replace the modified boot image as well as the modified kernel?
Follow the OP on this thread (https://forum.xda-developers.com/nexus-6p/general/guide-fix-nexus-6p-bootloop-death-blod-t3640279) in the downloads section there appear to be 2 files i would need, the "Boot.img from stock 6.17, 8.0 firmware" and "EX kernel version 5.03". Am i understanding that correctly?
Like i said, this is my only phone, and i'm probably just being overly paranoid about bricking it, but any clarification would be greatly appreciated.
johnnyphive said:
Thanks for the reply and the help. If i could ask for a little more help, as this is my only phone.
Can you explain the difference between the modified boot.img and the modified kernel?
If i download the factory image from here (https://developers.google.com/android/images) is it ok to the get the latested one (Nov 2017) or do i need to get the original one (Sep 2017 as i'm on Fi)
Once i flash the factory image, is it going to replace the modified boot image as well as the modified kernel?
Follow the OP on this thread (https://forum.xda-developers.com/nexus-6p/general/guide-fix-nexus-6p-bootloop-death-blod-t3640279) in the downloads section there appear to be 2 files i would need, the "Boot.img from stock 6.17, 8.0 firmware" and "EX kernel version 5.03". Am i understanding that correctly?
Like i said, this is my only phone, and i'm probably just being overly paranoid about bricking it, but any clarification would be greatly appreciated.
Click to expand...
Click to collapse
Use the latest November image. The boot.img contains the kernel and ramdisk, critical files necessary to load the device before the filesystem can be mounted. When you flash the new boot.img contained in the Google image, it will overwrite the patched kernel. You then need to re-patch it by installing EX kernel before booting. EX writes to (modifies) the stock boot.img. There are also pre-modifed boot.img files floating around. You will probably get more detailed help in the dedicated thread. Learning to flash manually (or remember how) is not really a big deal and a necessary skill for modding (and for getting yourself out of trouble). Good luck. :good:
v12xke said:
Use the latest November image. The boot.img contains the kernel and ramdisk, critical files necessary to load the device before the filesystem can be mounted. When you flash the new boot.img contained in the Google image, it will overwrite the patched kernel. You then need to re-patch it by installing EX kernel before booting. EX writes to (modifies) the stock boot.img. There are also pre-modifed boot.img files floating around. You will probably get more detailed help in the dedicated thread. Learning to flash manually (or remember how) is not really a big deal and a necessary skill for modding (and for getting yourself out of trouble). Good luck. :good:
Click to expand...
Click to collapse
Ok, so 1 last time (sorry)
1 - Downloaded the latest 8.0.0 factory image from google (this contains the bootloader, radio, and partitions (.zip).
2 - Get phone to fastboot and apply the above 3 new images
3- before rebooting, flash oreo4core (new, modified boot.img), TWRP recovery.img
4- reboot to recovery (TWRP) and apply the modified EX kernel
5 - reboot and (hopefully) profit
Am i missing anything, or doing anything that isn't needed?
johnnyphive said:
Ok, so 1 last time (sorry)
1 - Downloaded the latest 8.0.0 factory image from google (this contains the bootloader, radio, and partitions (.zip).
2 - Get phone to fastboot and apply the above 3 new images
3- before rebooting, flash oreo4core (new, modified boot.img), TWRP recovery.img
4- reboot to recovery (TWRP) and apply the modified EX kernel
5 - reboot and (hopefully) profit
Am i missing anything, or doing anything that isn't needed?
Click to expand...
Click to collapse
<<Disclaimer: I don't use the 4 core kernel, so I don't know if it comes with installer script or someone has just modified the latest boot.img>> Unzip the "partitions" zip you refer to and extract those image files to the same folder as bootloader and modem. For example, you can keep TWRP recovery if you don't flash the recovery.img. That is how you preserve your custom recovery. So in other words you'll now have a folder (your ADB folder?) with 5 image files.... bootloader, radio, boot, system, and vendor all in one folder. <<Note: it is my understanding you just substitute the latest oreo4core file (should be boot.img?) If this is true, copy that file into your ADB folder and let it overwrite the stock boot.img. Stop. Copy over flash-all.bat, change the *.bat extension to *.txt and open in notepad. You will see (and can copy/paste) the fastboot commands to get you started with bootloader and radio. Then flash the last 3 (boot, system, vendor). At this point you can reboot into the OS. Since you substituted the oreo4core boot.img file for the stock boot.img there is no need to use TWRP to flash anything. That and since you skipped flashing the recovery.img, TWRP is still there.
v12xke said:
<<Disclaimer: I don't use the 4 core kernel, so I don't know if it comes with installer script or someone has just modified the latest boot.img>> Unzip the "partitions" zip you refer to and extract those image files to the same folder as bootloader and modem. For example, you can keep TWRP recovery if you don't flash the recovery.img. That is how you preserve your custom recovery. So in other words you'll now have a folder (your ADB folder?) with 5 image files.... bootloader, radio, boot, system, and vendor all in one folder. <<Note: it is my understanding you just substitute the latest oreo4core file (should be boot.img?) If this is true, copy that file into your ADB folder and let it overwrite the stock boot.img. Stop. Copy over flash-all.bat, change the *.bat extension to *.txt and open in notepad. You will see (and can copy/paste) the fastboot commands to get you started with bootloader and radio. Then flash the last 3 (boot, system, vendor). At this point you can reboot into the OS. Since you substituted the oreo4core boot.img file for the stock boot.img there is no need to use TWRP to flash anything. That and since you skipped flashing the recovery.img, TWRP is still there.
Click to expand...
Click to collapse
Thank for the help! Everything seems to be up and running. I know you said you don't use the "4 cores" (can only assume your either on a different phone or yours isn't affected by the BLOD), but do you know if i still need to apply the EX kernel update, or know of a way to tell if it's already been applied?
Thanks again for all the help. I was pretty much in the right direction, but being as how i'd been away from it for a while, i wanted some backup
johnnyphive said:
Thank for the help! Everything seems to be up and running. I know you said you don't use the "4 cores" (can only assume your either on a different phone or yours isn't affected by the BLOD), but do you know if i still need to apply the EX kernel update, or know of a way to tell if it's already been applied? Thanks again for all the help. I was pretty much in the right direction, but being as how i'd been away from it for a while, i wanted some backup
Click to expand...
Click to collapse
I don't think you can flash EX kernel from now on. I think you have to use a modded boot.img that will contain his kernel/ramdisk. This is my guess. You really should be getting your information in the dedicated thread where everyone is actually installing and using it. Google "oreo 4 core" and you will find the XDA thread is the first hit. Good luck. :good:
Hi guys,
Sorry if it is a silly question but I have been trying to get the information with no results.
I have a Samsung galaxy s10+ SM G975F... It is binary 15 and when I use Odin, I can get a newer binary than 14... I want to downgrade from Android 12 to 11... The Batery drain is insane now...
Odin always said that the Binary is incorrect and can't flash any diferent rom
Any ideas or suggestions? Can I install a custom Rom at least?
Thanks and I hope you can help me.
Downgrading Samsung phones is pretty much impossible without unlocking bootloader some funky playing around (manually flashing system, boot, and probably way more) and a TON of luck. I could help you better with an older android Version as i dont have much experience with android 9 or newer.
Arash2803 said:
Hi guys,
Sorry if it is a silly question but I have been trying to get the information with no results.
I have a Samsung galaxy s10+ SM G975F... It is binary 15 and when I use Odin, I can get a newer binary than 14... I want to downgrade from Android 12 to 11... The Batery drain is insane now...
Odin always said that the Binary is incorrect and can't flash any diferent rom
Any ideas or suggestions? Can I install a custom Rom at least?
Thanks and I hope you can help me.
Click to expand...
Click to collapse
Bump same question my device is 16 and binary i want to install is 14? help
no, you CANT downgrade the binary but you can try make a rom with older version of android but expect bugs and a lot of issues due the bootloader
i got s10+ "G975FXXUFHVE1" i cant downgrade also im new to this whole stuff i really need help
🥹
Ch_ali134 said:
i got s10+ "G975FXXUFHVE1" i cant downgrade also im new to this whole stuff i really need help
Click to expand...
Click to collapse
Same boat here... S10+
i'm on G975FXXUGHVJ5 (android 12), so locked to bin 16. Wanted to go back to G975FXXSEFUL1 (android 11) So I could use my GearVR again, but that is bin 14... Backporting GearVR is out of the question... So i'm left with a feature downgraded p.o.s.. and this was the last moddel to support GearVR...
Pandoriaantje said:
Same boat here... S10+
i'm on G975FXXUGHVJ5 (android 12), so locked to bin 16. Wanted to go back to G975FXXSEFUL1 (android 11) So I could use my GearVR again, but that is bin 14... Backporting GearVR is out of the question... So i'm left with a feature downgraded p.o.s.. and this was the last moddel to support GearVR...
Click to expand...
Click to collapse
From what i've read, its mainly dowload mode/odin that does the check and blocks the downgrade. But what about converting an official samsung update to a flashable twrp/recovery zip? I already have a fully magisk rooted stock android 12 rom, i just want do downgrade the system to stock android 11 (rooted) for GearVR. I don't think actually loading the kernel/system is blocked at the bootloader lvl right?
Maybe with a rom kitchen it could be possible to convert to a flashable zip?
Pandoriaantje said:
From what i've read, its mainly dowload mode/odin that does the check and blocks the downgrade. But what about converting an official samsung update to a flashable twrp/recovery zip? I already have a fully magisk rooted stock android 12 rom, i just want do downgrade the system to stock android 11 (rooted) for GearVR. I don't think actually loading the kernel/system is blocked at the bootloader lvl right?
Maybe with a rom kitchen it could be possible to convert to a flashable zip?
Click to expand...
Click to collapse
Pandoriaantje said:
From what i've read, its mainly dowload mode/odin that does the check and blocks the downgrade. But what about converting an official samsung update to a flashable twrp/recovery zip? I already have a fully magisk rooted stock android 12 rom, i just want do downgrade the system to stock android 11 (rooted) for GearVR. I don't think actually loading the kernel/system is blocked at the bootloader lvl right?
Maybe with a rom kitchen it could be possible to convert to a flashable zip?
Click to expand...
Click to collapse
its only blocked when the bootloader is locked, you can just slap the files into an unsigned tar and it will flash fine with odin (bootloader cant be downgraded tho), but you will have to unlock bootloader and the binary version wont be downgraded just ignored
NigrumTredecim said:
its only blocked when the bootloader is locked, you can just slap the files into an unsigned tar and it will flash fine with odin (bootloader cant be downgraded tho), but you will have to unlock bootloader and the binary version wont be downgraded just ignored
Click to expand...
Click to collapse
NigrumTredecim said:
its only blocked when the bootloader is locked, you can just slap the files into an unsigned tar and it will flash fine with odin (bootloader cant be downgraded tho), but you will have to unlock bootloader and the binary version wont be downgraded just ignored
Click to expand...
Click to collapse
My bootloader is already unlocked. haven't tried downgrading through ODIN, as this is my Daily driver Phone, but i'dd love to get GearVR back. The phone is fully unlocked, with custom kernel, as per my Signature ... So (according to you) I should be able to downgrade to G975FXXSEFUL1 without error through ODIN? despite everyone claiming it can't be done? (I realise that the bootloader binary can't be downgraded, but ODIN/Download mode checks everything. Bootloader, kernel, etc.. no?)
What do you mean with "unsigned tar"?
side question: What about kernel? could I reuse/reflash (from TWRP) my current kernel (Ambasadii HVJ5, android 12) as it is pre-patched with latest magisk, on an older android 11 rom?
Pandoriaantje said:
My bootloader is already unlocked. haven't tried downgrading through ODIN, as this is my Daily driver Phone, but i'dd love to get GearVR back. The phone is fully unlocked, with custom kernel, as per my Signature ... So (according to you) I should be able to downgrade to G975FXXSEFUL1 without error through ODIN? despite everyone claiming it can't be done? (I realise that the bootloader binary can't be downgraded, but ODIN/Download mode checks everything. Bootloader, kernel, etc.. no?)
What do you mean with "unsigned tar"?
side question: What about kernel? could I reuse/reflash (from TWRP) my current kernel (Ambasadii HVJ5, android 12) as it is pre-patched with latest magisk, on an older android 11 rom?
Click to expand...
Click to collapse
unpack the stock tar.md5 using 7zip or some tool and repack it into a normal .tar, to my knowledge odin only checks the binary of original unmodified tar.md5 files like they come from samsung (my newest samsung is from 2017 so that may not be true anymore but it should still be)
for the kernel question i dont really know as i run android 8 with a modded stock kernel
NigrumTredecim said:
unpack the stock tar.md5 using 7zip or some tool and repack it into a normal .tar, to my knowledge odin only checks the binary of original unmodified tar.md5 files like they come from samsung (my newest samsung is from 2017 so that may not be true anymore but it should still be)
for the kernel question i dont really know as i run android 8 with a modded stock kernel
Click to expand...
Click to collapse
Any updates on this process, i would also give it a try if it works out.
crucknova said:
Any updates on this process, i would also give it a try if it works out.
Click to expand...
Click to collapse
not really, my newest samsung is an a5 2017 (where this process works fine)
but it should work, downside is that your bootloader needs to be unlocked as you build you own unsigned flashfile
EDIT: i cant get it to work anymore even tho thats how i did it the first time, flashing using a custom recovery will work tho if thats an option for you
QUICK TUTORIAL
1: download your desired stock firmware
2: extract AP****.tar.md5 (basically just a normal tar with signatures at the end use 7zip or any other program you know)
3: repack boot.img system.img vendor.img (vendor.img may not be there depending on the android version) into an uncompressed tar (using 7zip or any other program)
4: flash said tar using odin
you could also manually flash the image files using heimdall without repacking into an tar
NigrumTredecim said:
not really, my newest samsung is an a5 2017 (where this process works fine)
but it should work, downside is that your bootloader needs to be unlocked as you build you own unsigned flashfile
QUICK TUTORIAL
1: download your desired stock firmware
2: extract AP****.tar.md5 (basically just a normal tar with signatures at the end use 7zip or any other program you know)
3: repack boot.img system.img vendor.img (vendor.img may not be there depending on the android version) into an uncompressed tar (using 7zip or any other program)
4: flash said tar using odin
you could also manually flash the image files using heimdall without repacking into an tar
Click to expand...
Click to collapse
Thanks for the reply and a quick tutorial
NigrumTredecim​i have an s10 plus and a m30, im a bit hesirtant on trying it on s10 plus, but i will try the process on m30, as i need to downgrade it as well!
can you give me an more detailed tutorial on the 3rd step which includes repacking the boot.img system.img vendor.img, should i delete everything except these 3 and repack or what!
Thank you
download lz4 https://github.com/lz4/lz4/releases and drag and drop your .img.lz4 files onto the exe to get the img files
AAAAAAAAAAAAAAA i cant get it to work even though thats how i did it before already, using a custom recovery to flash the images will definitely work, so thats an option for you thats easier just unpack the .img.lz4 and skip the rest and flash using a custom recovery
just leaving the rest here in case somebody wants to find where i made the oopsie here
select your files in 7zip and then click the green plus in the top left corner
then pick tar in the format dropdown menu and then click ok to create the archive
then open said tar with odin
NigrumTredecim said:
download lz4 https://github.com/lz4/lz4/releases and drag and drop your .img.lz4 files onto the exe to get the img files
AAAAAAAAAAAAAAA i cant get it to work even though thats how i did it before already, using a custom recovery to flash the images will definitely work, so thats an option for you thats easier just unpack the .img.lz4 and skip the rest and flash using a custom recovery
just leaving the rest here in case somebody wants to find where i made the oopsie here
select your files in 7zip and then click the green plus in the top left corner
then pick tar in the format dropdown menu and then click ok to create the archive
then open said tar with odin
Click to expand...
Click to collapse
if i do a custom recovery the knox would trip and i wont be able to use the samsung pay. which i use a lot for payments. And thanks for your support dude.