Downgrade to 5.1.1 from latest MM fingerprint cm.bin discussion - Galaxy S6 Q&A, Help & Troubleshooting

Hello as you all know that we are be to downgrade to 5.1.1 using combination firmware and by flashing engineered bootloader sboot.bin. here https://forum.xda-developers.com/galaxy-s6/general/guide-how-to-downgrade-to-lolipop-t3545903
now the problem is fingerprint scanner is not working to get it working we need to flash cm.bin and sboot.bin from 5.1.1 firmware it gives sw rev error when flashing with odin. so I'm finding other ways to do it. i have tried dd commands from adb shell / su terminal like:
dd if=/sdcard/sboot.bin of=/dev/block/platform/15570000.ufs/by-name/BOTA0
dd if=/sdcard/cm.bin of=/dev/block/platform/15570000.ufs/by-name/BOTA1
also used bs and count
dd if=/sdcard/sboot.bin of=/dev/block/platform/15570000.ufs/by-name/BOTA0 bs=4096 count=1
it flashes ok but after reboot fingerprint don't work neither these two sboot and cm are downgraded
i also tried twrp to flash these same things happens now the question is there somebody more expert and experienced dev? who can help those many people who want to downgrade to 5.1.1 real original ui who don't like mm and grace ux.
how can we forcefully overwrite these bootloader files? please comment bellow i hope there could be a way. I''m on 5.1.1 reply any idea i can test instantly.

qasim799 said:
Hello as you all know that we are be to downgrade to 5.1.1 using combination firmware and by flashing engineered bootloader sboot.bin. here https://forum.xda-developers.com/galaxy-s6/general/guide-how-to-downgrade-to-lolipop-t3545903
now the problem is fingerprint scanner is not working to get it working we need to flash cm.bin and sboot.bin from 5.1.1 firmware it gives sw rev error when flashing with odin. so I'm finding other ways to do it. i have tried dd commands from adb shell / su terminal like:
dd if=/sdcard/sboot.bin of=/dev/block/platform/15570000.ufs/by-name/BOTA0
dd if=/sdcard/cm.bin of=/dev/block/platform/15570000.ufs/by-name/BOTA1
also used bs and count
dd if=/sdcard/sboot.bin of=/dev/block/platform/15570000.ufs/by-name/BOTA0 bs=4096 count=1
it flashes ok but after reboot fingerprint don't work neither these two sboot and cm are downgraded
i also tried twrp to flash these same things happens now the question is there somebody more expert and experienced dev? who can help those many people who want to downgrade to 5.1.1 real original ui who don't like mm and grace ux.
how can we forcefully overwrite these bootloader files? please comment bellow i hope there could be a way. I''m on 5.1.1 reply any idea i can test instantly.
Click to expand...
Click to collapse
This is risky but maybe if you format the partitions before you flash it may work.?

UltraGamerHD said:
This is risky but maybe if you format the partitions before you flash it may work.?
Click to expand...
Click to collapse
how can i format them if you are talking about twrp then can you give me correct updater script to format these partition and then flash files afterwards.
they are not ext4

Related

[STOCK][N] H850 20k OPEN EU ROM Flashable ZIPs + KDZ

Stock Firmware H850 v20k OPEN EU ROM
There is a newer version available: H850 v20q. Thread: https://forum.xda-developers.com/lg-g5/development/stock-h850-20q-eu-rom-flashable-zips-kdz-t3707040
[Update 14-12-2017] Downloads removed to gain storage for newer versions.
KDZ-File: H85020k_00_OPEN_EU_OP_0822.kdz (MD5)
Flashable ZIP Complete: LG-H85020K-Flashable.COMPLETE.zip (MD5)
Flashable ZIP Boot: LG-H85020K-Flashable.Boot.zip (MD5)
Flashable ZIP Bootloader: LG-H85020K-Flashable.Bootloader.zip (MD5)
Flashable ZIP Modem: LG-H85020K-Flashable.Modem.zip (MD5)
Android 7.0
Patch level: 1st August 2017
Baseband: MPSS.TH.2.0.c1.4-00047-M8996FAAAANAZM-1.101802.1.109832.1
Kernel: 3.18.31
Build: NRD90U
Tested it with TWRP 3.1.1 and SuperSu v2.82.
Instructions: Please use autoprime's H850 20D install directions here: https://forum.xda-developers.com/lg-g5/development/stock-h850-20d-eu-rom-flashable-zips-t3592762.
To build the ZIPs I used parts of autoprime's previous files. Thx to him.
Has anyone already tried to upgrade from v20a to v20k using the complete.zip?
Thanks a lot. I have to go back from LineageOS because there are so much bugs
Nice that you upload all these images. What is your source?
cleaned
Can I upgrade my stock LG G5 ( 20i ) to this, using LGUP?
Is this the latest Android version for G5? Can I root it?
@DavidFlint
I'm on Fulmics ROM 4.5. To flash Bootloader zip, do I need to do full wipe or can I just flash bootloader and then boot back into the rom without loosing any data?
Sent from my LG-H850 using XDA-Developers Legacy app
Kirparon said:
Thanks a lot. [...] Nice that you upload all these images. What is your source?
Click to expand...
Click to collapse
You're welcome. The source for the KDZ is LG. I did the the ZIP files by myself using the KDZ data and parts of autoprime's work.
SergiuStatache said:
Can I upgrade my stock LG G5 ( 20i ) to this, using LGUP?
Click to expand...
Click to collapse
Yes, should work with the kdz file.
giebeka said:
Is this the latest Android version for G5? Can I root it?
Click to expand...
Click to collapse
At the moment, yes. H850 20K implements some security updates (small update). Rooting as I mentioned works with SuperSU 2.82: just flash it in TWRP after the H850 20K ZIP.
I flashed this rom with the latest twrp but now every time my phone reboots in recovery. I tries to reflash or re-download but it's the same... Please help me. I'm with H850
sseleman13 said:
I flashed this rom with the latest twrp but now every time my phone reboots in recovery. I tries to reflash or re-download but it's the same... Please help me. I'm with H850
Click to expand...
Click to collapse
Sounds like the famous twrp bootloop.
Try entering through the terminal:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/misc bs=256 count=1 conv=notrunc
You might then need to install SU s well..
Randomuser666 said:
Sounds like the famous twrp bootloop.
Try entering through the terminal:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/misc bs=256 count=1 conv=notrunc
You might then need to install SU s well..
Click to expand...
Click to collapse
I solved flashing stock european firmware with LG-UP and uppercut. So i re-flashed fulmics rom.
ATZ-007 said:
@DavidFlint
I'm on Fulmics ROM 4.5. To flash Bootloader zip, do I need to do full wipe or can I just flash bootloader and then boot back into the rom without loosing any data?
Sent from my LG-H850 using XDA-Developers Legacy app
Click to expand...
Click to collapse
I would really appreciate a reply to this this.
Thanks [emoji2]
Sent from my LG-H850 using XDA-Developers Legacy app
Randomuser666 said:
Sounds like the famous twrp bootloop.
Try entering through the terminal:
dd if=/dev/zero of=/dev/block/bootdevice/by-name/misc bs=256 count=1 conv=notrunc
You might then need to install SU s well..
Click to expand...
Click to collapse
Didn't work, unfortunately.
I thought I did everything right, but got into the recovery loop, fixed by flashing a KDZ via LGUP. What caused the issue in the first place? Should I now re-root the damn thing?
totalnoob34 said:
Didn't work, unfortunately.
I thought I did everything right, but got into the recovery loop, fixed by flashing a KDZ via LGUP. What caused the issue in the first place? Should I now re-root the damn thing?
Click to expand...
Click to collapse
Hmm, I had the twrp boot loop when I flashed LOS, so I'm pretty sure it is a twrp-problem.
try one of the solutions described here:
https://forum.xda-developers.com/lg-g5/help/stuck-twrp-recovery-t3587077
There are several other entries about the twrp-loop and the G5 as well...
It is very, very easy to lose twrp or end up in the twrp loop with the G5. I had both problems and figured out that you have to be very careful about how how flash new roms, or update roms, or when to flash SU etc.. you will have to google it...
I think it's a bit of a hit and miss situation here...
I guess the reason why you had the problem was, coz you didn't flash SU immediately after flashing the rom but probably tried to boot it first...
When I was trying to figure out why I was constantly ending up in a twrp loops or losing twrp (actually not being able to access it, was not lost...) or root.. I was thinking for days WTF, WTF...
sseleman13 said:
I flashed this rom with the latest twrp but now every time my phone reboots in recovery. I tries to reflash or re-download but it's the same... Please help me. I'm with H850
Click to expand...
Click to collapse
My G5 did the same a while ago. When I remember right I was able to fix that with re-flash of TWRP in bootloader, then flash COMPLETE ZIP and SuperSU in TWRP. Have you tried this?
Take it as a rule, flash rom+supersu always, without to reboot betweem
Sent from my P027 using XDA-Developers Legacy app
Maybe a stupid question, but since I got magik I have to flash the rom, then magisk again...without reboot.
What about the screen retention? Fixed?
Anyone know if Anti rollback is still 00? Also I noticed 20P is out already.
rosboy said:
Anyone know if Anti rollback is still 00? Also I noticed 20P is out already.
Click to expand...
Click to collapse
It is. See attached screenshot.
Thanks, I tested 20P and it is also able to rollback. I'm back to Marshmallow. Couldn't get xposed working.

[Discussion] Hard-Brick Infos, Success or Failure of Updates.

Considering that lately there were quite a few hard-bricks, I invite the users that experienced such bricks to post more details here.
Please use this model when you post :
Similar discussion is done in Mate 10 forums ( https://forum.xda-developers.com/mate-10/how-to/discussion-hard-brick-infos-t3789044 ) too I request all to share their experience.
Please also read this thread made by @ante0 - > https://forum.xda-developers.com/mate-10/how-to/beware-bla-l29c432b147-t3817241 <- you will also find a tool that will help you check the xloader.img
Upload your xloader.img to any file hosting and share us the link so that we can together find a solution for the issues.
1) Device = device codename (COL-L29 C432, AL-10 C00, etc)
2) Firmware and Region before Brick = exact firmware and region (B134 C636, B141 C432)
3) Firmware that lead to brick = The firmware version that lead to bricking
4) You were trying to just update your device or you were also trying to rebrand
5) Your device was rebranded or used stock region?
6) Other infos of modifications, update procedures, etc that you did before bricking
7) xloader.img image
8) Result of Xloader.img check tool ( https://forum.xda-developers.com/mate-10/how-to/beware-bla-l29c432b147-t3817241 ) if possible screen shots.
Thank you and please stay on topic!
Credits for @Pretoriano80 for the idea and @ante0 for the xloader check tool.
1) Device = Honor 10 (COL-L29)
2) Firmware and Region before Brick = COL-L29 8.1.0.106 (SP6C900)
3) Firmware that lead to brick =COL-L29C432B120 (8.1.0.120)
4) Trying to just update the device and also trying to rebrand from SP6C900 to C432
5) Used stock region and not rebranded.
6) Used HuRUpdater to update from COL-L29 8.1.0.106 (SP6C900) to COL-L29C432B120 but gave wrong device info so tried to use no check recovery from Honor V10 but it failed so again tried HuRUpdater to flash COL-L29C432B104 and boom got a hard bricked device. Except black screen nothing happened.
DELETED
@flattervieh , @NekoMichi , @mrspeccy , @awells845 can you please share your experience while updating.
My device did not brick, and the update was applied successfully.
1. Device - Honor 10 (COL-L29)
2. FW before update - COL-L29C432B120 (8.1.0.120)
3. FW after update - COL-L29C432B145 (8.1.0.145)
4. Update only, did not attempt to rebrand.
5. Device had not been rebranded beforehand.
6. Device was originally rooted by flashing ramdisk image from here.
Magisk version 16.4
Magisk manager version 5.8.3 (129)
Xposed 3.1.4 was also installed
Custom recovery used: TWRP
HuRUpdater used: Version 0.3
Prior to updating, I had removed all passwords/fingerprints/face unlock data.
After the installation was complete in TWRP, I cleared cache and Dalvik cache before rebooting.
I haven't used Xloader.
miststudent2011 said:
1) Device = Honor 10 (COL-L29)
2) Firmware and Region before Brick = COL-L29 8.1.0.106 (SP6C900)
3) Firmware that lead to brick =COL-L29C432B120 (8.1.0.120)
4) Trying to just update the device and also trying to rebrand from SP6C900 to C432
5) Used stock region and not rebranded.
6) Used HuRUpdater to update from COL-L29 8.1.0.106 (SP6C900) to COL-L29C432B120 but gave wrong device info so tried to use no check recovery from Honor V10 but it failed so again tried HuRUpdater to flash COL-L29C432B104 and boom got a hard bricked device. Except black screen nothing happened.
Click to expand...
Click to collapse
Well, HuRUpdater is not intended for rebrand and that was your first mistake (even if it wasn't the real problem).
Second, you tried to downgrade instead of trying to rebrand with NoCheck Recovery (that would have fixed your initial issue).
Third, there's not much to do for your device now and only a fix/replacement from Huawei will revive it.
You should check the xloader.img for COL-L29C432B120 and COL-L29C432B104, at least you could understand if xloader was the culprit or just the downgrade (mixed-up operations you did previously).
Pretoriano80 said:
Well, HuRUpdater is not intended for rebrand and that was your first mistake (even if it wasn't the real problem).
Second, you tried to downgrade instead of trying to rebrand with NoCheck Recovery (that would have fixed your initial issue).
Third, there's not much to do for your device now and only a fix/replacement from Huawei will revive it.
You should check the xloader.img for COL-L29C432B120 and COL-L29C432B104, at least you could understand if xloader was the culprit or just the downgrade (mixed-up operations you did previously).
Click to expand...
Click to collapse
Well, HuRUpdater is not intended for rebrand and that was your first mistake -- >Mine shows region as EU only which is COL-L29 so I dont think I am trying to rebrand (may be wrong).
Second, you tried to downgrade instead of trying to rebrand with NoCheck Recovery --> Tried with the same build but it did not work just failed installation, so tried with lower build it too gave same error.
You should check the xloader.img for COL-L29C432B120 and COL-L29C432B104 --> Currently dont have the files will re download and check them.
BTW do you have any idea of how to check extract currently installed build Xloader from mobile ?
miststudent2011 said:
Well, HuRUpdater is not intended for rebrand and that was your first mistake -- >Mine shows region as EU only which is COL-L29 so I dont think I am trying to rebrand (may be wrong).
Second, you tried to downgrade instead of trying to rebrand with NoCheck Recovery --> Tried with the same build but it did not work just failed installation, so tried with lower build it too gave same error.
You should check the xloader.img for COL-L29C432B120 and COL-L29C432B104 --> Currently dont have the files will re download and check them.
BTW do you have any idea of how to check extract currently installed build Xloader from mobile ?
Click to expand...
Click to collapse
2) Firmware and Region before Brick = COL-L29 8.1.0.106 (SP6C900) <- this looks like demo unit or something,clearly not C432 (hw/eu).
So it seems that you tried to flash a firmware not intended for your region. Or maybe i'm missing something?
Pretoriano80 said:
2) Firmware and Region before Brick = COL-L29 8.1.0.106 (SP6C900) <- this looks like demo unit or something,clearly not C432 (hw/eu).
So it seems that you tried to flash a firmware not intended for your region. Or maybe i'm missing something?
Click to expand...
Click to collapse
Yes it is a Demo unit , In settings while I looked for device info it showed as International and hw/eu . So I am assuming its a EU variant(not sure).
miststudent2011 said:
Yes it is a Demo unit , In settings while I looked for device info it showed as International and hw/eu . So I am assuming its a EU variant(not sure).
Click to expand...
Click to collapse
The correct procedure would have been this:
1)Rebrand with NoCheck Recovery from demo to C432
2)Flash a FullOTA for C432,profit!
miststudent2011 said:
BTW do you have any idea of how to check extract currently installed build Xloader from mobile ?
Click to expand...
Click to collapse
From a terminal:
dd if=/dev/block/sda of=/sdcard/xloader.img
(This requires TWRP at least)
Then transfer to computer to check manually or:
You can then run the xxd command, though this requires busybox
xxd -s 0x1a8 -l 1 /sdcard/XLOADER.img | grep '000001a8: 01'> /dev/null && echo "01 XLOADER. Safe when going 01 to 01, 01 to 02. 02 to 01 WILL brick" || echo "02 XLOADER. Safe when going 02 to 02. 02 to 01 WILL brick
ante0 said:
From a terminal:
dd if=/dev/block/sda of=/sdcard/xloader.img
(This requires TWRP at least)
Then transfer to computer to check manually or:
You can then run the xxd command, though this requires busybox
xxd -s 0x1a8 -l 1 /sdcard/XLOADER.img | grep '000001a8: 01'> /dev/null && echo "01 XLOADER. Safe when going 01 to 01, 01 to 02. 02 to 01 WILL brick" || echo "02 XLOADER. Safe when going 02 to 02. 02 to 01 WILL brick
Click to expand...
Click to collapse
Thanks for the command I will try it, can you also give commands to backup stock recovery before flashing twrp , and similar command for all other partitions
miststudent2011 said:
Thanks for the command I will try it, can you also give commands to backup stock recovery before flashing twrp , and similar command for all other partitions
Click to expand...
Click to collapse
For recovery you can actually do
dd if=/dev/block/bootdevice/by-name/erecovery_ramdisk of=/dev/block/bootdevice/by-name/recovery_ramdisk
This will write erecovery ramdisk to recovery ramdisk, as they both use the same image.
For other partitions you can use dd too, but they become rather large as dd copies the whole partition rather than just occupied data.
Example: dd if=/dev/block/bootdevice/by-name/system of=/sdcard/system.img
If it complains about /dev/block/bootdevice you have to use the full platform path or figure out whats linked to what.
You can 'cd' to /dev/block/platform/xxxxxxx/by-name/
Xxxxxx= platform dependent, not sure what Honor 10 uses.
Then use 'ls -la' there to show where symlinks go, and you should then see that system is linked to /dev/block/sdd59
Then you can just dd if=/dev/block/sdd59 of=/sdcard/system.img
miststudent2011 said:
Thanks for the command I will try it, can you also give commands to backup stock recovery before flashing twrp , and similar command for all other partitions
Click to expand...
Click to collapse
If you don't have busybox installed, you can open the xloader.img from sdcard with this app - > https://play.google.com/store/apps/details?id=com.kos.binaryviewer <- go to "000001a8" offset and check if it has the 01 or 02 switch.
ante0 said:
For recovery you can actually do
dd if=/dev/block/bootdevice/by-name/erecovery_ramdisk of=/dev/block/bootdevice/by-name/recovery_ramdisk
This will write erecovery ramdisk to recovery ramdisk, as they both use the same image.
For other partitions you can use dd too, but they become rather large as dd copies the whole partition rather than just occupied data.
Example: dd if=/dev/block/bootdevice/by-name/system of=/sdcard/system.img
If it complains about /dev/block/bootdevice you have to use the full platform path or figure out whats linked to what.
You can 'cd' to /dev/block/platform/xxxxxxx/by-name/
Xxxxxx= platform dependent, not sure what Honor 10 uses.
Then use 'ls -la' there to show where symlinks go, and you should then see that system is linked to /dev/block/sdd59
Then you can just dd if=/dev/block/sdd59 of=/sdcard/system.img
Click to expand...
Click to collapse
Do I need root for this or just stock is enough ? or as suggested above do i need twrp ?
Firmware for my version is not available so wanted to make sure before proceeding. Doesnt want to hard brick one more device.
miststudent2011 said:
Do I need root for this or just stock is enough ? or as suggested above do i need twrp ?
Firmware for my version is not available so wanted to make sure before proceeding. Doesnt want to hard brick one more device.
Click to expand...
Click to collapse
Root is mandatory if TWRP is not installed.
Pretoriano80 said:
Root is mandatory if TWRP is not installed.
Click to expand...
Click to collapse
Image link from your previous post is broken ?
miststudent2011 said:
Do I need root for this or just stock is enough ? or as suggested above do i need twrp ?
Firmware for my version is not available so wanted to make sure before proceeding. Doesnt want to hard brick one more device.
Click to expand...
Click to collapse
Pretoriano80 said:
Root is mandatory if TWRP is not installed.
Click to expand...
Click to collapse
And TWRP is fine if no root
dd works even with the adb enabled mankindtw recovery, so you would just need that if you don't want to flash TWRP.
But you will need one if them... I guess TWRP would be better as you can backup ramdisk that way and keep it stock.
But if Honor 10 was released with 8.1 I'm pretty sure it has a 02 xloader already, P20 has had it since the first firmware and its most likely why dc/fh doesn't work for it.
ante0 said:
And TWRP is fine if no root [emoji14]
dd works even with the adb enabled mankindtw recovery, so you would just need that if you don't want to flash TWRP.
But you will need one if them... I guess TWRP would be better as you can backup ramdisk that way and keep it stock.
But if Honor 10 was released with 8.1 I'm pretty sure it has a 02 xloader already, P20 has had it since the first firmware and its most likely why dc/fh doesn't work for it.
Click to expand...
Click to collapse
That's why i'm curious if COL-L29C432B104 has 01 or 02 xloader. [emoji6]
Pretoriano80 said:
That's why i'm curious if COL-L29C432B104 has 01 or 02 xloader. [emoji6]
Click to expand...
Click to collapse
Oh, it's 01
http://imgur.com/a/qMCjPDi

[GUIDE] Skipping KG STATE prenormal on OneUI (Android Pie 9.0)

Hello, XDA Community.​
Since the release of the last major update, Android Pie 9.0/OneUI, as soon as we trigger an update to the bootloader while we are running unofficial binaries, like TWRP and custom ROMs, a message pops up on boot splash when we perform a simple reboot:
"Only official released binaries are allowed to be flashed"
This message shows up when we have KG State Prenormal (you can check KG State by entering download mode).
Before the Pie update, we were able to skip RMM State Prenormal by setting system date for 7 days before current date, then triggering a "check for system update", then setting back to current date. However, this doesn't work on the new Pie bootloader, which is why I am writing this guide, as I got caught many times into this damn state
The workaround I've found is downgrading bootloader from Pie to Oreo, but, as we know, after flashing Pie bootloader, we are not able to downgrade it to Oreo using Odin, however it's possible forcing the downgrade using Heimdall on Ubuntu.
REQUIREMENTS:
1. Ubuntu 16.04+
2. Heimdall (install it through Ubuntu terminal)
sudo apt install heimdall-flash
Click to expand...
Click to collapse
3. 'cm.bin' + 'modem.bin' + 'sboot.bin' files from Oreo firmware (you can get them by extracting BL and CP .tar files from the official stock firmware zip - download them on SamFirm, SamMobile or updato.com)
4. Internet connection (important - needed to download PIT file)
5. Attention while typing the commands
GUIDE:
1. Boot your phone into download mode (Power + Vol (-) + Bixby, then Vol (+) to enter download mode)
2. Place cm.bin + modem.bin + sboot.bin into your Ubuntu user folder (/home/username/) - check attachment
3. Open terminal (Ctrl + Alt + T)
4. Type the following command:
heimdall flash --CM cm.bin --RADIO modem.bin --BOOTLOADER sboot.bin
Click to expand...
Click to collapse
5. It should take about 5 seconds. After that, you're done and now you can flash unofficial binaries (e.g. TWRP), or even fully downgrade to Oreo, if you got fed up with Pie :laugh:
I hope this helps anybody. If this guide helped you, leave me a 'Thanks' and/or drop a comment.
Yours sincerely,
James​
^ I flash TWRP normally through Odin, at this point KG state is "Checking"
Reboot to recovery, if you try to flash something at this point it fails since it can't mount data and system if I remember correctly, either you format them or change the filesystem for the partitions that can't be mounted to another format and then again to the original format(ext4). Now you can flash dm-verity disable and a custom ROM. This was my case. I don't know about the rmm state bypass you mentioned earlier. The only thing I know is that KG State is set to Checking, and stays like that.
i have all files but flasher i mean heimdall-suite-1.4.0-win32 its not working because me PC is win 7 64 Bit so what must i do need help please.
and i got this flash file G955FXXU4CRL3 and some device like Z3X, UMT, Chimera ETC.. can i use this device or u will give me any other tool?
THX.
I thought Heimdall didn't work for s8 and new firmware
then whats is the solution for RMM Status prenomal ?
talhagsm said:
i have all files but flasher i mean heimdall-suite-1.4.0-win32 its not working because me PC is win 7 64 Bit so what must i do need help please.
and i got this flash file G955FXXU4CRL3 and some device like Z3X, UMT, Chimera ETC.. can i use this device or u will give me any other tool?
THX.
Click to expand...
Click to collapse
"win32"? I have tested this solution on Ubuntu. I can't guarantee this works with Windows 7, sorry
talhagsm said:
then whats is the solution for RMM Status prenomal ?
Click to expand...
Click to collapse
On Oreo, I used to follow this guide:
https://forum.xda-developers.com/ga...iscussion/stoping-damn-rmm-prenormal-t3883519
However, this doesn't work with Pie/OneUI
TheMadScientist said:
I thought Heimdall didn't work for s8 and new firmware
Click to expand...
Click to collapse
Worked for me while downgrading DSBA to CSB1 bootloader
jameskunst said:
Worked for me while downgrading DSBA to CSB1 bootloader
Click to expand...
Click to collapse
Last I heard it hadn't been updated. I stand corrected
thank you
but how to remove KG State Prenormal if i want stay on pie
like i have file to remove rmm state and byebass
are there any way to byebass KG State or remove
Can I use this to get back to nougat?
Whats the best way to 'extract' the BL & CP files? If I use 7zip in windows or archive manager in linux it gives me cm.bin.lz4 & sboot.bin.lz4 etc. Do I rename these or use them as is?
kgr said:
Whats the best way to 'extract' the BL & CP files? If I use 7zip in windows or archive manager in linux it gives me cm.bin.lz4 & sboot.bin.lz4 etc. Do I rename these or use them as is?
Click to expand...
Click to collapse
I used linux dude, lz4 is another form of compression, like zip etc.
If you rename the files it'll fail.
In parrot linux, lz4 wasn't installed.
##so I downloded it first##
sudo apt-get install lz4
##then i used lz4 to decompress each of the files##
lz4 -d modem.bin.lz4
this will decompress and spit out the modem.bin file you're after.
---------- Post added at 11:11 AM ---------- Previous post was at 11:01 AM ----------
SM-G950F
SO I successfully flashed the required .bin files in linux to the phone as per the guide.
Booted back into windows to used odin and tried flashing twrp-3.2.3-2-dreamlte.img.tar
Still failed with "only official released binaries etc" error on the bootloader after Odin fails.
RMM prenormal still showing on the bootloader.
Is this normal and I have to wait another 7 days or should this have worked?
what is KG gate?
there's no need to go through all that, just reflash BL,CP & Home from Oreo Stock rom.Then you can reflash TWRP after that,atleast thats what i did on G965N Pie and it worked
flash this using odin
done
peeyemv said:
flash this using odin
done
Click to expand...
Click to collapse
On AP tab?
LU SONEVESSO said:
On AP tab?
Click to expand...
Click to collapse
If your going to flash it then yes use AP section in Odin.
I threw my S8 Fury can not do anything oem unlock no longer appears now I have an S10 .... XD The Life is Strange
Psydt0n3 said:
I used linux dude, lz4 is another form of compression, like zip etc.
If you rename the files it'll fail.
In parrot linux, lz4 wasn't installed.
##so I downloded it first##
sudo apt-get install lz4
##then i used lz4 to decompress each of the files##
lz4 -d modem.bin.lz4
this will decompress and spit out the modem.bin file you're after.
---------- Post added at 11:11 AM ---------- Previous post was at 11:01 AM ----------
SM-G950F
SO I successfully flashed the required .bin files in linux to the phone as per the guide.
Booted back into windows to used odin and tried flashing twrp-3.2.3-2-dreamlte.img.tar
Still failed with "only official released binaries etc" error on the bootloader after Odin fails.
RMM prenormal still showing on the bootloader.
Is this normal and I have to wait another 7 days or should this have worked?
Click to expand...
Click to collapse
yeah, the same here with s8+, done with linux and went back to windows, flashed twrp and fails, i don't know what to do now
the only different thing was the phone state was custom, but still rmm was lock
i even flashed stock oreo but nothing
and i must say, the linux thing is a pain in the ass, that procedure is not for everyone,im a soft engineer and it took me 2H
peeyemv said:
flash this using odin
done
Click to expand...
Click to collapse
doesn't work, get "SECURE CHECK FAIL : (BOOTLOADER)" in download mode and state is still Prenormal

Downgrading Bootloader in Samsung

Does anyone know how to downgrade bootloader in Samsung (M51)? I'm trying to rollback to OneUI 2.5 from 3.1 but it keeps giving me sw error
Wondering what sense it would make to downgrade phone's bootloader:
A bootloader helps to load the operating system or runtime environment to add programs to memory and provide access for components. It is needed to run the startup process, initialize the hardware, and pass control to the kernel, which initializes the operating system.
AlanDias17 said:
Does anyone know how to downgrade bootloader in Samsung (M51)? I'm trying to rollback to OneUI 2.5 from 3.1 but it keeps giving me sw error
Click to expand...
Click to collapse
No, you can't downgrade bootloader on Samsung unless the downgraded bootloader has a binary version equal to the binary version of your currently installed bootloader. For example, if the binary version of your currently installed bootloader is binary 4, you can flash the downgraded bootloader if it is also binary 4 but you cannot flash a bootloader that is binary 3, 2 or 1.
xXx yYy said:
Wondering what sense it would make to downgrade phone's bootloader:
A bootloader helps to load the operating system or runtime environment to add programs to memory and provide access for components. It is needed to run the startup process, initialize the hardware, and pass control to the kernel, which initializes the operating system.
Click to expand...
Click to collapse
Downgrading bootloader in order to flash custom recovery or root the device is a common practice if the currently installed bootloader can't be unlocked or does not allow flashing TWRP or rooting.
xXx yYy said:
Wondering what sense it would make to downgrade phone's bootloader:
A bootloader helps to load the operating system or runtime environment to add programs to memory and provide access for components. It is needed to run the startup process, initialize the hardware, and pass control to the kernel, which initializes the operating system.
Click to expand...
Click to collapse
Rationally speaking I'd rather stay on stable version of Android 10 OneUI 2.5 than on Android 11 OneUI 3.1. For me, it's buggy and camera quality got worsen. Updated bootloader isn't the issue but it's the reason I can't downgrade my OS.
Droidriven said:
No, you can't downgrade bootloader on Samsung unless the downgraded bootloader has a binary version equal to the binary version of your currently installed bootloader.
Click to expand...
Click to collapse
So now it's impossible in my situation since bootloader versions don't match since September security patch. Now that sucks.
AlanDias17 said:
So now it's impossible in my situation since bootloader versions don't match since September security patch. Now that sucks.
Click to expand...
Click to collapse
That is usually the case for Samsung owners. In the past, downgrading was possible but not on today's device's. It is rare and few and far between that a Samsung can be downgraded these days. Virtually impossible across the board. This is something to consider when buying Samsung devices and when a stock update is possible.
Me personally, I never update a device with stock updates unless things start having issues or stop working due to not updating to keep up with changing technology. I don't update unless absolutely necessary, I put the update off as long as possible.
My current device has been notifying me for months that an update is available but I have it paused so that it doesn't download. Maybe I'll update at some point in the future, maybe not.
AlanDias17 said:
So now it's impossible in my situation since bootloader versions don't match since September security patch. Now that sucks.
Click to expand...
Click to collapse
There is one potential workaround to downgrade, you can try extracting the system.img from the downgraded firmware then convert it to an Odin flashable .tar using 7zip to compress the file .tar format, select the highest level of compression. After extracting the system.img but before converting to .tar, try extracting the system.img itself then find where the kernel is packaged in the system.img then try finding what the binary version of the kernel is, if the kernel's binary version is lower than the binary version of the currently installed kernel, you will not be able to flash the extracted system.img with the kernel packaged inside it, you will have to try removing it then convert to .tar as I described. Once you verified binary versions, convert the file to .tar then flash the system.img.tar.md5 via Odin, place the system.img.tar.md5 in the AP slot.
Basically, it works like this, if you boot into download mode and look at the revision values, you should see something like this:
swREV B: x K: x S: x
B is for bootloader binary version, K is for kernel binary version and S is for system binary version. If B is lower than your currently installed B version, you can't flash it, if K is lower than your currently installed K version, you can't flash it, if S is lower than your currently installed S version, you can't flash it. See if you can find out what the binary version of your currently installed bootloader, kernel and system are, then compare them to the binary version of the downgraded firmwares bootloader, kernel and system. B, K and S can be independent different values, for example, a firmware could have a B value of 4, a K value of 6 and a S value of 5, they do not always all 3 have the same value in a single firmware. Some updates may come with an updated B binary and an updated K binary but not an S binary, or any combination. In my example above, if a device has values of B: 4 K:6 S:5 and that device receives an update that has B:5 and S7 but no updated K value, after flashing, the device would have B:5 K:6 and S:7.
If any of the parts of the downgraded firmware have a binary version that is equal to its corresponding currently installed component, it can be flashed, but if any of them are lower than their corresponding currently installed components, they can't be flashed.
Sorry to be so long winded, just trying to explain how binary version works and can possibly be manipulated to downgrade each individual element, if the binary versions correspond correctl.
Droidriven said:
There is one potential workaround to downgrade, you can try extracting the system.img from the downgraded firmware then convert it to an Odin flashable .tar using 7zip to compress the file .tar format, select the highest level of compression. After extracting the system.img but before converting to .tar, try extracting the system.img itself then find where the kernel is packaged in the system.img then try finding what the binary version of the kernel is, if the kernel's binary version is lower than the binary version of the currently installed kernel, you will not be able to flash the extracted system.img with the kernel packaged inside it, you will have to try removing it then convert to .tar as I described. Once you verified binary versions, convert the file to .tar then flash the system.img.tar.md5 via Odin, place the system.img.tar.md5 in the AP slot.
Basically, it works like this, if you boot into download mode and look at the revision values, you should see something like this:
swREV B: x K: x S: x
B is for bootloader binary version, K is for kernel binary version and S is for system binary version. If B is lower than your currently installed B version, you can't flash it, if K is lower than your currently installed K version, you can't flash it, if S is lower than your currently installed S version, you can't flash it. See if you can find out what the binary version of your currently installed bootloader, kernel and system are, then compare them to the binary version of the downgraded firmwares bootloader, kernel and system. B, K and S can be independent different values, for example, a firmware could have a B value of 4, a K value of 6 and a S value of 5, they do not always all 3 have the same value in a single firmware. Some updates may come with an updated B binary and an updated K binary but not an S binary, or any combination. In my example above, if a device has values of B: 4 K:6 S:5 and that device receives an update that has B:5 and S7 but no updated K value, after flashing, the device would have B:5 K:6 and S:7.
If any of the parts of the downgraded firmware have a binary version that is equal to its corresponding currently installed component, it can be flashed, but if any of them are lower than their corresponding currently installed components, they can't be flashed.
Sorry to be so long winded, just trying to explain how binary version works and can possibly be manipulated to downgrade each individual element, if the binary versions correspond correctl.
Click to expand...
Click to collapse
can you try If it is possible to downgrade like this, I would like to downgrade the s10e and s7 versions. It would be great if you could make a guide for it.
kullanici32 said:
can you try If it is possible to downgrade like this, I would like to downgrade the s10e and s7 versions. It would be great if you could make a guide for it.
Click to expand...
Click to collapse
I don't think you get the bigger picture.
I was not saying "you absolutely CAN downgrade if you do it like this".
I was saying "IF it is even possible, you can TRY doing it like this".
I don't know if it would work or not on your specific model number, there are too many variables involved in whether it will be successful or not.
I don't own this specific model number so I cant test anything to see if it will work, not to mention that I'm not doing all that research or putting that kind of time, work and energy into making anything for a device that I don't own or use.
I've just given the idea and "possibility" of downgrading based on how some other Samsung devices have been able to successfully downgrade the OS(system) by extracting the system.img from the downgraded firmware and flashing the system.img by itself without flashing the rest of the firmware. This is not the same as downgrading the whole firmware, you're only replacing the upgraded system with the previous version of system but only "IF" the binary versions for system and kernel do not conflict.
If you want to know how to do this or if it will even work on your specific model number, you will have to do your own research, your own thinking and your own hard work to figure it out based on how other Samsung owners have done it.
There are threads here that describe doing this on various other Samsung models. They don't all go about it exactly the same, there are differences in the details and methods based on various device specific software requirements and restrictions. You might or might not be successful, you could even brick your device if you get something wrong. Find other threads that describe how others did it and then try the methods that they used but use your firmware files to make the changes that they made.
Droidriven said:
I don't think you get the bigger picture.
I was not saying "you absolutely CAN downgrade if you do it like this".
I was saying "IF it is even possible, you can TRY doing it like this".
I don't know if it would work or not on your specific model number, there are too many variables involved in whether it will be successful or not.
I don't own this specific model number so I cant test anything to see if it will work, not to mention that I'm not doing all that research or putting that kind of time, work and energy into making anything for a device that I don't own or use.
I've just given the idea and "possibility" of downgrading based on how some other Samsung devices have been able to successfully downgrade the OS(system) by extracting the system.img from the downgraded firmware and flashing the system.img by itself without flashing the rest of the firmware. This is not the same as downgrading the whole firmware, you're only replacing the upgraded system with the previous version of system but only "IF" the binary versions for system and kernel do not conflict.
If you want to know how to do this or if it will even work on your specific model number, you will have to do your own research, your own thinking and your own hard work to figure it out based on how other Samsung owners have done it.
There are threads here that describe doing this on various other Samsung models. They don't all go about it exactly the same, there are differences in the details and methods based on various device specific software requirements and restrictions. You might or might not be successful, you could even brick your device if you get something wrong. Find other threads that describe how others did it and then try the methods that they used but use your firmware files to make the changes that they made.
Click to expand...
Click to collapse
Can you put or give us a link to such a thread or post, we will follow the steps for our own device firmware.
What would be a way to use a TWRP backup with a v3 on a device that has say a v5 boot
Packtlike said:
What would be a way to use a TWRP backup with a v3 on a device that has say a v5 boot
Click to expand...
Click to collapse
If using TWRP, you should, "in theory", be able to flash whatever you want, including an older backup.
Droidriven said:
After extracting the system.img but before converting to .tar, try extracting the system.img itself then find where the kernel is packaged in the system.img
Click to expand...
Click to collapse
Could you please explain how do I go about "extracting the system.img iself"?
Droidriven said:
No, you can't downgrade bootloader on Samsung unless the downgraded bootloader has a binary version equal to the binary version of your currently installed bootloader. For example, if the binary version of your currently installed bootloader is binary 4, you can flash the downgraded bootloader if it is also binary 4 but you cannot flash a bootloader that is binary 3, 2 or 1.
Click to expand...
Click to collapse
What does "unless" mean in the first sentence above? I mean, if the only possibility for replacing an installed bootloader is using another bootloader with equal or higher binary version, then we are not downgrading anything, or are we? I am a bit confused.
zogoibi said:
Could you please explain how do I go about "extracting the system.img iself"?
Click to expand...
Click to collapse
Extract the contents from the firmware file to get to the various .img/bin files in the firmware, find the system.img file, extract it's contents to get to the various files/folders in the system img. Then you find whatever parts of the system.img that you want/need then do whatever it is that you need to do with them.
zogoibi said:
What does "unless" mean in the first sentence above? I mean, if the only possibility for replacing an installed bootloader is using another bootloader with equal or higher binary version, then we are not downgrading anything, or are we? I am a bit confused.
Click to expand...
Click to collapse
It means that it is possible to have a firmware that has a lower "bootloader" version than the firmware currently installed on a device but an equal "binary"version as the firmware currently installed. For example, if a device has firmware installed on it that has bootloader "y" with binary 4, they could flash a firmware that has bootloader "x"(x being lower than y) and the same binary 4, equivalent binary but lower actual bootloader version, which downgrades the bootloader version but not the binary version. If it had bootloader "x" but had binary 3 or lower, then, yes, what you say would apply.
Droidriven said:
Extract the contents from the firmware file to get to the various .img/bin files in the firmware, find the system.img file, extract it's contents to get to the various files/folders in the system img. Then you find whatever parts of the system.img that you want/need then do whatever it is that you need to do with them.
Click to expand...
Click to collapse
Thank you. I already got that I have to gut apart system.img. But my question was: how do I do that? Anyway, I already found the answer: using simg2img command to transform system.img to raw format, then loopmounting it. But now, how do I find the kernel file as per your comment above: "find where the kernel is packaged in the system.img" ? There are one thousand files inside, and none of them seem to qualify as the kernel. Besides, on a developer forum I've read that the kernel is not inside system.img, but inside boot.img. And how to gut apart boot.img?
After a good deal of search, it seems I got the answer to that question too: getting a copy of android_booting_tools, which has the command unpackbootimg (since abootimg couldn't do the job and exited with error "not a valid Android Boot image") Once unpacked boot.img, voilá, the kernel is there (and definitely not inside system.img): the file named boot.img-zimage.
BUT!! Now, what do I want the kernel file for, if what I need is to downgrade the bootloader? Your instructions are a bit unclear in that point.
Droidriven said:
It means that it is possible to have a firmware that has a lower "bootloader" version than the firmware currently installed on a device but an equal "binary"version as the firmware currently installed. For example, if a device has firmware installed on it that has bootloader "y" with binary 4, they could flash a firmware that has bootloader "x"(x being lower than y) and the same binary 4, equivalent binary but lower actual bootloader version, which downgrades the bootloader version but not the binary version. If it had bootloader "x" but had binary 3 or lower, then, yes, what you say would apply.
Click to expand...
Click to collapse
OK. I think I understood this part. Thanks.
zogoibi said:
Thank you. I understood what you meant: gut apart system.img. But my question was: how do I do that? Anyway, I already found the answer: using simg2img command to transform system.img to raw format, then loopmounting it. But now, how do I find the kernel as per your comment above: "find where the kernel is packaged in the system.img" ? There are one thousand files inside, and none of them seem to qualify as the kernel. Besides, as I've searched out there, in a developer forum I've read that the kernel is not in system.img, but in boot.img. And how to gut apart boot.img?
It seems I got the answer to that question either: downloading android_booting_tools, which has the command unpackbootimg (since abootimg couldn't do the job and exited with error "not a valid Android Boot image") Once unpacked boot.img, voilá, the kernel is there (and definitely not in system.img): the file named boot.img-zimage.
BUT!! Now, what the heck do I do with the kernel file, if what I need is to downgrade the bootloader? Your instructions are a bit unclear in that point.
OK. I think I understood this part. Thanks.
Click to expand...
Click to collapse
I use 7zip.
You asked how to extract the system.img, not the kernel.
The boot.img is not the bootloader. If you're trying to downgrade the bootloader then you should be trying to use the bootloader, but you may or may not need other parts of the downgraded firmware also in order for the bootloader to not cause the device to hard rock or block the flash. What you would or wouldn't need, I don't know, it usually requires tinkering to find the right recipe. Trial and error, experimenting with mixing different parts of each firmware to see what will or won't work together.
Also, it may require unlocking the bootloader and/or using a modified version of Odin to flash a modified firmware or modified .img files.
That is all "IF" it is even possible or safe to attempt Your milage may vary.
Droidriven said:
You asked how to extract the system.img, not the kernel.
Click to expand...
Click to collapse
I begun by quoting a post where you supposedly explained a 'potential' workaround for downgrading the bootloader (I qhote: "there is one potential workaround to downgrade"). As per your instructions, one should first extract 'system.img itself' in order to get hold of the kernel. And that's why I asked how to do it. Obviously the end point was to find the kernel, as per your instructions. But it turned out the kernel is not in system.img. I wonder what Is, then, the point in that part of your instructions.
Droidriven said:
The boot.img is not the bootloader.
Click to expand...
Click to collapse
Obviously not. I haven't said that. I just said that I found out that kernel is inside boot.img, not inside system.img.
Droidriven said:
If you're trying to downgrade the bootloader then you should be trying to use the bootloader
Click to expand...
Click to collapse
Well, I can also say: "if you're trying to help people downgrading the bootloader (which is the title of this thread), then you should be trying to help people downgrading the bootloader."
Droidriven said:
There is one potential workaround to downgrade, you can try extracting the system.img from the downgraded firmware then convert it to an Odin flashable .tar using 7zip to compress the file .tar format, select the highest level of compression. After extracting the system.img but before converting to .tar, try extracting the system.img itself then find where the kernel is packaged in the system.img then try finding what the binary version of the kernel is, if the kernel's binary version is lower than the binary version of the currently installed kernel, you will not be able to flash the extracted system.img with the kernel packaged inside it, you will have to try removing it then convert to .tar as I described. Once you verified binary versions, convert the file to .tar then flash the system.img.tar.md5 via Odin, place the system.img.tar.md5 in the AP slot.
Basically, it works like this, if you boot into download mode and look at the revision values, you should see something like this:
swREV B: x K: x S: x
B is for bootloader binary version, K is for kernel binary version and S is for system binary version. If B is lower than your currently installed B version, you can't flash it, if K is lower than your currently installed K version, you can't flash it, if S is lower than your currently installed S version, you can't flash it. See if you can find out what the binary version of your currently installed bootloader, kernel and system are, then compare them to the binary version of the downgraded firmwares bootloader, kernel and system. B, K and S can be independent different values, for example, a firmware could have a B value of 4, a K value of 6 and a S value of 5, they do not always all 3 have the same value in a single firmware. Some updates may come with an updated B binary and an updated K binary but not an S binary, or any combination. In my example above, if a device has values of B: 4 K:6 S:5 and that device receives an update that has B:5 and S7 but no updated K value, after flashing, the device would have B:5 K:6 and S:7.
If any of the parts of the downgraded firmware have a binary version that is equal to its corresponding currently installed component, it can be flashed, but if any of them are lower than their corresponding currently installed components, they can't be flashed.
Sorry to be so long winded, just trying to explain how binary version works and can possibly be manipulated to downgrade each individual element, if the binary versions correspond correctl.
Click to expand...
Click to collapse
Hi, I know this thread is quite old. But i have a Rooted Galaxy M23 (SM-M236B) and in odin it says B:2 K:2 S:2. I was waiting for an software update and sawed that there was one update in that it says that is bit is 3, Questions: 1. If I install the bit 3 software i would not be able to install again a 2 bit software? 2. My bootloader is unlocked, does applying the update locks the bootloader? And 3. How do I know if the update makes my bootloader locked permanently?
Mr. Electrinix said:
Hi, I know this thread is quite old. But i have a Rooted Galaxy M23 (SM-M236B) and in odin it says B:2 K:2 S:2. I was waiting for an software update and sawed that there was one update in that it says that is bit is 3, Questions: 1. If I install the bit 3 software i would not be able to install again a 2 bit software? 2. My bootloader is unlocked, does applying the update locks the bootloader? And 3. How do I know if the update makes my bootloader locked permanently?
Click to expand...
Click to collapse
1) yes, if you flash the binary 3 update, you will not be able to downgrade to a 2 binary, UNLESS the bootloader is unlocked and you use "patched Odin" or Cosmy's Odin to flash the downgraded firmware.
2) I don't know if flashing the update will lock the bootloader or not, you would have to research that yourself to see what results other users of your exact same model got after flashing the exact same update build number that your update has.
3) You would have to find other users that have the exact same model number device that you have and find a user that has flashed the exact update that you are asking about.
***Note***
If the update that you are asking about is a atock OTA update via the system update option in system settings, you will have to unroot the device then boot into recovery and wipe the cache partition (but not factory reset) then reboot the device, then do the update via settings. Stock OTA updates cannot safely be applied on devices that have been rooted, modified system partition or have custom recovery installed. You have to have clean, unrooted, unmodified stock firmware with stock recovery.
If you are manually flashing the update via Odin, you do not need to unroot before flashing the update, flashing via Odin "should" take care of that for you, depending on whether the update is a full update with a new system partition or a partial, incremental update.
Droidriven said:
1) yes, if you flash the binary 3 update, you will not be able to downgrade to a 2 binary, UNLESS the bootloader is unlocked and you use "patched Odin" or Cosmy's Odin to flash the downgraded firmware.
Click to expand...
Click to collapse
You can NEVER downgrade the bootloader/binary/bit level, even if you've bootloader unlocked it. OEM Unlock does NOT magically enable you to downgrade the binary

Downgrading G611F to a lower bootloader

Hello, i was trying to downgrade my phone from OneUI (Android 9) to samsung experience (Android 7) on G611F because latest version makes the device too slow for me and also i like samsung experience more than OneUI but seems that even when bootloader is unlocked it can't be downgraded from S3 to U1 and i face sw rev. check fail (bootloader) device 3, binary 1 error.. unfortunately trying to flash without BL gives same error with kernel (boot image).. is there any workaround to get this working? The bootloader already unlocked and i don't bother tripping knox or use custom recovery to flash stock old rom but i don't know if that would work or will give me same error during boot with kernel and other partitions.. also i'm worried about using a custom recovery to flash BL and downgrade bootloader by writting the old one directly to the proper partition with dd in terminal as i don't know if doing this will hard brick the device or not..
Is there any way i can use to downgrade to stock samsung experience rom?..
Thanks!
Same question sir...?

Categories

Resources