I've always had trouble finding a definitive answer for this question.
In general, are bootloaders backwards compatible? For example, if I flash a JB 4.2 bootloader, will flashing a JB 4.1 or ICS ROM work as expected, or does the bootloader need to be downgraded too? I know that some newer phones (like the S4) have an efuse that prevents going backwards (at least for stock), but does that concept hold true for all phones?
I have an S2 that I just replaced with an S4, so I'm going to play around with it some now (currently on stock 2.3.4 KH7 with rooted kernel). It's been a while since I've flashed an entire ROM (usually I just work on getting root), but since this won't me my primary phone anymore, I can play around with it a bit.
I can't give you a definitive answer. We have established that even though the file size for the boot loaders remains consistent from Gingerbread through jelly bean, there are differences between the files when examined as hex code. So the engineers do perform modifications with each version. I have never seen any discussion of the boot loaders not being backward compatible. So, since we have lots of stock and custom firmware on the forum that does not contain boot loaders, I would assume that you could flash a Gingerbread or ICS over JB or KitKat boot loaders without problems. And even if there were issues, it would be no problem to flash a full stock distribution to get the correct boot loaders. But again, this is only my surmise, and not based on direct knowledge.
There have been some statements by at least one developer that you must upgrade the boot loaders for the latest versions of Jelly Bean or KitKat. I would think it advisable to have matching boot loaders on your daily driver.
(apologies ahead of time that my initial post was probably in the wrong forum).
Well, at least I'm not the only one who hasn't been able to find a definitive answer.
Speaking specifically about the S2 (since that seems to be one of your specialties), if I need to update the bootloader to ICS or JB (since I'm on gingerbread) and something goes wrong, will it hard brick the phone or can I still get into the ODIN download mode to recover/reflash? Is the download mode on this phone considered part of the bootloader? I get a little confused sometimes in regards to what is included in the "module".
For example, it seems like (at least for this phone), the recovery image is built into the kernel as opposed to a separate image like my ASUS Transformer TF300T. Is that correct? On my TF300T, I can flash the recovery image separately through fastboot without touching the kernel, bootloader, or anything else, but it seems like the recovery image for the S2 always comes with a kernel.
Basically, I want to do anything I can ahead of time to reduce the risk of a brick (and know what I should avoid to reduce bricking the phone). Based upon what you said, it sounds like the best way to upgrade my bootloader is to flash a stock ROM that includes the bootloader. If that is the case, since JB 4.1 was the last version release by AT&T, should I just go to that bootloader and hope it works if I install a JB 4.2/4.3 or KitKat based ROM? I assume if I reflashed the stock KH7 ROM, it would just replace everything (including bootloader) and get me back to where I am now?
I have a lot of experience in the Linux world, so I'm trying to map over the Android concepts to the Linux concepts, but I still get tripped up sometimes (recovery, bootloader, kernel, ROM, etc). Sometimes people don't seem to use the terms the same way.
From a technical standpoint, it doesn't surprise me too much that the bootloaders are the same size. It's probably similar to the MBR code for hard drives that just does a minimalistic job of getting the hardware in an accessible state so it can later boot the kernel (like GRUB).
jpasher said:
(apologies ahead of time that my initial post was probably in the wrong forum).
Click to expand...
Click to collapse
Yes, questions are usually supposed to go in the Q&A forum, but there is not so much activity in this phone's forum any more, so it really doesn't matter much. And this information is more of a general nature anyway.
Well, at least I'm not the only one who hasn't been able to find a definitive answer.
Speaking specifically about the S2 (since that seems to be one of your specialties), if I need to update the bootloader to ICS or JB (since I'm on gingerbread) and something goes wrong, will it hard brick the phone or can I still get into the ODIN download mode to recover/reflash? Is the download mode on this phone considered part of the bootloader?
Click to expand...
Click to collapse
1. Hard brick on an android phone generally means that one of the boot loaders is corrupt, or it might mean that the memory module section that contains the boot loaders or other low level code is damaged. In general, the main thing you have to be careful about is when flashing a boot loader to make sure that the flash is not interrupted. For instance, say the power goes out, or the dog pulls out the usb cord, right in the middle of the flash, and after the boot loader partition is wiped, only part of the code is copied back to the partition. The good news is that the individual bootloaders are fairly small, so the time of vulnerability is a matter of seconds.
If you need to update to ICS or JB boot loaders, you would have to flash the full stock distribution that has the boot loaders included. No one has made Odin flashable tars of either of those. The UCKH7 Gingerbread secondary boot loader is available in tar, and that is the only separate tar I know of.
2. I don't know software engineering, only a little programming. I don't know where the code that puts the phone into download mode is located. It seems likely that it is in the secondary boot loader, but that is only speculation. I do know that you can enter download mode, and then flash both boot.bin and/or sbl.bin.
I get a little confused sometimes in regards to what is included in the "module". For example, it seems like (at least for this phone), the recovery image is built into the kernel as opposed to a separate image like my ASUS Transformer TF300T. Is that correct? On my TF300T, I can flash the recovery image separately through fastboot without touching the kernel, bootloader, or anything else, but it seems like the recovery image for the S2 always comes with a kernel.
Click to expand...
Click to collapse
1. The memory is partitioned. Each chunck of code is loaded into its specific partition. I don't have a partition table handy for the S2, but essentially you have: primitive boot loader (boot.bin), secondary boot loader (sbl.bin), parameters (param.lfs), kernel (zImage or boot.img), cache (cache.img), system (factoryfs.img), hidden (hidden.img), modem (modem.img) and several others like PIT, EFS, CSC and I don't remember what. But the ones I named are what is included in a full firmware distribution, and the AT&T model does not allow for the changing of the CSC like on the international S2 so that is not used. I'm not a Linux person, but if my understanding is correct, the img files install like a block device, but the boot loaders and param at a lower level.
2. There may be a recovery partition, but I'm not sure of that. If there is, it isn't used. Anyway, you are correct that the recovery is compiled into the kernel and is installed as a unit on the S2. You can not install a separate recovery on the S2. Many Android phones, maybe most as far as I know, do have a separate partition for the recovery. The S3 and S4 do also.
3. If you are interested, I have attached a partition table for the S4, which you might want to look at just for interest and learning. If memory serves me, it is quite a bit different from the S2.
Basically, I want to do anything I can ahead of time to reduce the risk of a brick (and know what I should avoid to reduce bricking the phone). Based upon what you said, it sounds like the best way to upgrade my bootloader is to flash a stock ROM that includes the bootloader. If that is the case, since JB 4.1 was the last version release by AT&T, should I just go to that bootloader and hope it works if I install a JB 4.2/4.3 or KitKat based ROM? I assume if I reflashed the stock KH7 ROM, it would just replace everything (including bootloader) and get me back to where I am now?
Click to expand...
Click to collapse
I would assume that the above is correct. The boot loaders in the 4.1.2 UCMD8 firmware would be the latest official ones for this phone. As far as flashing back to earlier stock, you would only get the boot loaders if you use a full distribution. Many of the stock distributions and almost all of the custom firmware posted on this site for the AT&T S2 do not contain boot loaders or param.lfs.
I have a lot of experience in the Linux world, so I'm trying to map over the Android concepts to the Linux concepts, but I still get tripped up sometimes (recovery, bootloader, kernel, ROM, etc). Sometimes people don't seem to use the terms the same way.
From a technical standpoint, it doesn't surprise me too much that the bootloaders are the same size. It's probably similar to the MBR code for hard drives that just does a minimalistic job of getting the hardware in an accessible state so it can later boot the kernel (like GRUB).
Click to expand...
Click to collapse
A lot of people around here (myself included) speak from anecdotal information gathered from the forums.
Wow. A LOT of useful information in that response. Thanks! A few of the things finally made some light bulbs go on in my head and clear some things up.
creepyncrawly said:
If you need to update to ICS or JB boot loaders, you would have to flash the full stock distribution that has the boot loaders included. No one has made Odin flashable tars of either of those. The UCKH7 Gingerbread secondary boot loader is available in tar, and that is the only separate tar I know of.
Click to expand...
Click to collapse
So to get to an ICS or JB bootloader, does it mean I have to perform an update through Kies? I'm looking at the different custom ROMs running KitKat and at least some of them say to be on a JB bootloader. I've read that at least some some devices (such as my TF300T), the different bootloader versions can actually have different partition layouts
If I tried flashing your OCD package for UCLL6 4.0.4 on my current system (with gingerbread BL), would it boot (or worst case, just not boot but still allow me to enter ODIN download mode to flash back to stock UCKH7)? If I'm understanding things correctly, it seems like as long as I'm not touching the bootloader, the worst thing that could happen is that I get an unbootable phone that I can still recover using ODIN download mode.
creepyncrawly said:
2. I don't know software engineering, only a little programming. I don't know where the code that puts the phone into download mode is located. It seems likely that it is in the secondary boot loader, but that is only speculation. I do know that you can enter download mode, and then flash both boot.bin and/or sbl.bin.
Click to expand...
Click to collapse
I guess I'll have to start poking around the different partitions to see if I can find any signs that point to what is what (unless I can't do a simple dd of the partition to a file using adb shell).
creepyncrawly said:
1. The memory is partitioned. Each chunck of code is loaded into its specific partition. I don't have a partition table handy for the S2, but essentially you have: primitive boot loader (boot.bin), secondary boot loader (sbl.bin), parameters (param.lfs), kernel (zImage or boot.img), cache (cache.img), system (factoryfs.img), hidden (hidden.img), modem (modem.img) and several others like PIT, EFS, CSC and I don't remember what. But the ones I named are what is included in a full firmware distribution, and the AT&T model does not allow for the changing of the CSC like on the international S2 so that is not used. I'm not a Linux person, but if my understanding is correct, the img files install like a block device, but the boot loaders and param at a lower level.
Click to expand...
Click to collapse
Very useful stuff. I'll have to read around a bit more to understand the different functions associated with each image. And yes, it would make sense that the img files are simply a direct bit-for-bit copy of that partition (which I would assume could be obtained with a simple dd copy). That would also explain why the bootloaders are the same size (if you dd a block device/partition, the resulting raw file is the size of the block device/partition). My guess is that the flashing process essentially just takes each img and does the same thing as a dd of the file to the partition.
This makes me wonder... If the bootloader partition for a phone has a JB BL, I can't see why someone couldn't do a dd of that partition into an image file and then restore that to the bootloader partition of another phone (maybe there's built in security that prevents stuff like that).
creepyncrawly said:
3. If you are interested, I have attached a partition table for the S4, which you might want to look at just for interest and learning. If memory serves me, it is quite a bit different from the S2.
Click to expand...
Click to collapse
Very nice. Thanks. I just got my S4 last month, so I don't plan on doing anything to it besides already acquiring root. I'm also on the MF3 release which doesn't have any known way of installing custom ROMs anyway.
I wouldn't use Kies. Flash the full distribution of the stock firmware that you want the boot loader. For JB boot loaders, flash UCMD8 full. You can find that in the Download Repository at the bottom of the page.
The OCD for UCKK6 does not have boot loaders. To get the Gingerbread boot loaders, flash UCKH7 full. To get the ICS boot loaders, flash UCLE5 or UCLL6 full. Again, you can get those in the Download Repository.
You can use dd to pull or restore the contents of a partition. You can use adb shell, or you can use terminal emulator right on the phone. In fact, it's a good idea to back up your efs partition using the dd command. I've posted how to do that several times in the forums. Advanced search for "back up efs" and "creepyncrawly" should find that for you.
I personally would never try to flash a bootloader using the dd command, although it is definitely possible. There is too much margin for error. Remember, the dd command is lovingly called the destroy disk command.
wait. I've never flashed any bootloader. My phone came with GB but the last official firmware that my phone had was the ICS OTA. From there, I flashed up to JB and now I'm happily running KK.
I have flashed the latest modem, however.
Unless I am missing something, my phone works just fine with old bootloaders and new kernel/recovery/roms.
Sent from my SGH-I777 using XDA Premium 4 mobile app
Once again, thanks for the useful info.
I would definitely only use dd to replace the contents of a partition as a last resort. Since I don't know enough about how android would handle a partition being changed underneath its feet, it would be risky.
I grabbed the file for UCMD8 (4.1.2) and I'll play around with that. I tried to grab UCLL6 (4.0.4) too, but the links point to the defunct hotfile site. Do you have updated links for that file (or is it exactly the same as what I can download at sammobile.com)? The full stock binaries (.tar.md5) go in the ODIN PDA slot, right?
Also, for those that may be interested, I made a copy of the bootloader from my stock UCKH7 (partition /dev/block/mmcblk0p2) and looked for strings related to the ODIN download mode, and I was able to find all of the strings that appear when in download (e.g. "ODIN MODE", "PRODUCT NAME", "ERASING DOWNLOAD INFORMATION", etc), so it's safe to say that ODIN download mode is part of the bootloader. All the more reason to just leave the bootloader alone if possible.
I also noticed that the two bootloader partitions (mmcblk0p2 and mmcblk0p3) are almost identical except for the text string SNBL in the mmcblk0p2 partition. I wonder why the two partitions...
bleggy said:
wait. I've never flashed any bootloader. My phone came with GB but the last official firmware that my phone had was the ICS OTA. From there, I flashed up to JB and now I'm happily running KK.
Click to expand...
Click to collapse
Which JB version are you running? One possible reason I can think of where a newer bootloader would be needed is if the partition layout changes. I've heard of some devices where that occurred with JB 4.2. Maybe that's why TWRP recovery has two different versions for 4.1 and 4.2 on my TF300T.
At any rate, it's good to hear that someone hasn't broken their phone by running an older bootloader with a newer ROM.
I'm on KitKat 4.2.2 now.
Previously, 4.3 & 4.2-something Jellybean. And a ICS rom before that.
I dont think flashing new bootloaders is necessary. I mean, I dont think its common.
Sent from my SGH-I777 using XDA Premium 4 mobile app
jpasher said:
I grabbed the file for UCMD8 (4.1.2) and I'll play around with that. I tried to grab UCLL6 (4.0.4) too, but the links point to the defunct hotfile site. Do you have updated links for that file (or is it exactly the same as what I can download at sammobile.com)? The full stock binaries (.tar.md5) go in the ODIN PDA slot, right?
Click to expand...
Click to collapse
I haven't finished uploading files to dev-host yet. But I'll be sure to upload that one today. I don't think you can get the file from sammobile either. They also used hotfile, and have not re-uploaded their complete library yet.
Yes, put the tar.md5 in the pda slot.
Also, for those that may be interested, I made a copy of the bootloader from my stock UCKH7 (partition /dev/block/mmcblk0p2) and looked for strings related to the ODIN download mode, and I was able to find all of the strings that appear when in download (e.g. "ODIN MODE", "PRODUCT NAME", "ERASING DOWNLOAD INFORMATION", etc), so it's safe to say that ODIN download mode is part of the bootloader. All the more reason to just leave the bootloader alone if possible.
Click to expand...
Click to collapse
So you dd'd the contents of 0p2 and looked at that? What tool did you use to look for strings? And do you know if that is boot.bin or sbl.bin? I think it must be boot.bin.
I also noticed that the two bootloader partitions (mmcblk0p2 and mmcblk0p3) are almost identical except for the text string SNBL in the mmcblk0p2 partition. I wonder why the two partitions...
Click to expand...
Click to collapse
Is it possible that there is built in redundancy? If one partition is bad, the second one can be used?
I have uploaded UCLL6 Odin Flashable tar.md5 to dev-host and posted it in the Download Repository.
By the way, I forgot so didn't mention it earlier in the discussion, but both UCLE5 and UCLL6 contain boot bin, but do not contain either sbl.bin or param.lfs. Evidently, the secondary boot loader and param files were not updated in the upgrade from Gingerbread to ICS.
Thanks for the files. One more question about them. If I simply remove the boot.bin and sbl.bin from the tar file and flash, that's the same as the "no bootloader" flash images, right? Maybe param.lfs too? I'm just thinking of ways to make things safer while I'm doing my initial testing (and bleggy seems to be running newer ROMs off the original GB bootloader).
creepyncrawly said:
So you dd'd the contents of 0p2 and looked at that? What tool did you use to look for strings? And do you know if that is boot.bin or sbl.bin? I think it must be boot.bin.
Click to expand...
Click to collapse
It was definitely the SBL, because it's a 1.25MB image instead of the 128K first stage bootloader. I found this thread about the Captivate (another extra phone I have) that says it works the same way (and does a good job explaining the boot process). I haven't figured out where the first stage bootloader (boot.bin) is stored, since it's not in a partition. I'll have to do some research on that.
In Linux, there's actually a command called strings that you can run on a file and it will extract all of the text strings it can find. A grep of that can find specific text. You could of course do the same thing by opening the file in a hex editor.
Is it possible that there is built in redundancy? If one partition is bad, the second one can be used?
Click to expand...
Click to collapse
That was my thought, but I'm not brave enough to experiment to see if that's true.
whats the point, anyway? having consistent bootloader and rom doesnt seem to matter and plenty of i777 owners are running kitkat which there is no available bootloader to download and flash.
Is this an OCD thing? I get flashing the various modems for signal improvement, but I've never had a problem booting any rom with my old GB or ICS bootloader.
Sent from my SGH-I777 using XDA Premium 4 mobile app
jpasher said:
One more question... If I simply remove the boot.bin and sbl.bin from the tar file and flash, that's the same as the "no bootloader" flash images, right? Maybe param.lfs too?
Click to expand...
Click to collapse
Yes, that would be true. As long as you are using Linux to tar the remaining files, they should flash fine. I guess you can add the md5 if you want also.
The UCLE5 and UCLL6 one-click downloaders that I posted have the boot.bin removed. The UCLE5 and UCLL6 stock plus root also have the boot.bin removed. No one has ever said anything about any problems resulting.
My assumption is that it's ok to keep gingerbread boot loaders, or to flash the ICS boot loader, or to flash the JB boot loaders, and you would never be able to tell the difference. On the other hand, there must be a reason that Samsung puts them into the kies download. I just have no knowledge and no speculation on how they differ, or whether it is important to have matching boot loaders.
Edit: Oh, and boot.bin probably goes into 0p0 partition, just a guess. But it gets flashed in the pda slot just like sbl and param, so it must go into a partition.
Edit: A forum friend found this thread for us.
Edit: I just found Adam Outler's online pit file analyzer and ran the pit file from the Download Repository through it. Partition information for the AT&T SGS2 attached.
bleggy said:
whats the point, anyway? having consistent bootloader and rom doesnt seem to matter and plenty of i777 owners are running kitkat which there is no available bootloader to download and flash.
Click to expand...
Click to collapse
I have no reason to make the bootloader match the ROM. I'm just making sure I understand how everything works together to avoid doing something that may potentially brick my phone. I flashed the no bootloader version of stock UCMD8 today and everything seems to be working fine. As long as things work, I don't really care which bootloader I have.
creepyncrawly said:
Edit: Oh, and boot.bin probably goes into 0p0 partition, just a guess. But it gets flashed in the pda slot just like sbl and param, so it must go into a partition.
Click to expand...
Click to collapse
There's not a "zero" partition. My only guess is that it's embedded somewhere else. Not sure at this point.
I found that post the other day with the S2 partition layout (that's what I was using for my tests). The PIT file analysis gives a little more info, although it says boot.bin partition is 0 bytes. That's what confuses me a bit. But in the end, not really a big deal. More of a curiosity than anything else.
When this forum was active "Don't mess with bootloaders" was common knowledge. Unless you absolutely have to. You can hard brick this thing if there's a problem while flashing it.
Don't mess with any of the files you mentioned. As far as I know it's unnecessary. I'm running Renders CM11 build with no problems with the original GB bootloader. Never had a problem with ICS or JB roms either.
Yea, my main purpose for starting the thread was to make sure I wouldn't break anything beyond repair by having mismatched bootloaders. It makes perfect sense why corrupting the bootloader would hose things (just like if you corrupted the MBR of your hard drive and had to boot off of alternative media to repair it, except for the fact that the phone does not have the ability to boot alternative media). My ASUS Transformer TF300T is nice in that aspect as the Nvidia chipset allows booting into APX mode which is an extremely low level boot mode that allows repair of almost anything. It should would be nice if the additional bootloader slot on the S2 could be used as a fallback with a way to choose which bootloader to run.
I'm the kind of person that likes to know more about the innards of how something works instead of looking at it as a black box. When I'm "flashing the kernel", I like to know exactly what it is I'm changing so I can understand the repercussions, especially if something goes wrong.
So the net result after this conversation is that I'm a lot more confident about flashing android devices (as long as I stay clear of messing with the bootloader whenever possible). I have CM11 running now too (stock CM kernel) while still on the GB bootloader.
Hi guys n girls,
I am sort of new to the Ace section here. I am doing a re-vamp of my mum's phone and said I would spruce it up a little. Shame there is no decent CM 9 versions that I can get working because of lack of RAM....the only one listed (no disrespect to the dev - thanks for making it available on such a low spec device!) but it doesn't work with my Optus GT S5830V (5830I) for some reason?
Anyway to my point, I have downloaded several versions of the stock firmware from Sammobile. The odd thing is that I cannot extract that firmware at all. Every archive program I have sees it as either being not an archive; corrupt or fails to extract it? So I am unable to make my own 4 part Odin recovery package. Making my own will save time; at the moment I have to flash the 4 part Odin (return to stock) package, then reboot into download mode again and then flash the stock firmware?
3 things I noted.
1). The device is not detected by the so called Odin specific for Ace and variants that uses an Ops type PIT file? The device is plugged in and all drivers upto date....it' just plain doesn't see it? It is however detected and flashable (albeit without an .ops file) using the 4 part package on Odin 3.07 made for my Galaxy S3?
2). I am unable to get any detection with EFS pro and it returns no PIT file?
3). All attempts to extract the stock Optus firmware package fail. I have removed the .MD5 file extension (only needed for preserving file naming conventions anyway - i.e. If you rename any .tar.md5 firmware package, in order to be able to flash it you need only to remove the .md5 from the end and leaving it as .tar and the firmware will flash without error. I digress.....What does someone suggest for me to being able to make my own firmware package based on stock?
First off, wrong section.
Jarmezrocks said:
Shame there is no decent CM 9 versions that I can get working because of lack of RAM....the only one listed (no disrespect to the dev - thanks for making it available on such a low spec device!) but it doesn't work with my Optus GT S5830V (5830I) for some reason?
Click to expand...
Click to collapse
1) We don't have a stable CM9 because our devs don't have the source code for all the drivers, not lack of RAM.
2) Have you formatted your system's partitions to the EXT4 filesystem? CM requires an EXT4 filesystem to operate.
Jarmezrocks said:
Anyway to my point, I have downloaded several versions of the stock firmware from Sammobile. The odd thing is that I cannot extract that firmware at all. Every archive program I have sees it as either being not an archive; corrupt or fails to extract it? So I am unable to make my own 4 part Odin recovery package. Making my own will save time; at the moment I have to flash the 4 part Odin (return to stock) package, then reboot into download mode again and then flash the stock firmware?
Click to expand...
Click to collapse
Jarmezrocks said:
3). All attempts to extract the stock Optus firmware package fail. I have removed the .MD5 file extension (only needed for preserving file naming conventions anyway - i.e. If you rename any .tar.md5 firmware package, in order to be able to flash it you need only to remove the .md5 from the end and leaving it as .tar and the firmware will flash without error. I digress.....What does someone suggest for me to being able to make my own firmware package based on stock?
Click to expand...
Click to collapse
The tar.md5 file has to split into the PDA, CSC, Modem and PIT files using Odinatrix. Search for it.
Jarmezrocks said:
3 things I noted.
1). The device is not detected by the so called Odin specific for Ace and variants that uses an Ops type PIT file? The device is plugged in and all drivers upto date....it' just plain doesn't see it? It is however detected and flashable (albeit without an .ops file) using the 4 part package on Odin 3.07 made for my Galaxy S3?
Click to expand...
Click to collapse
The Odin specific for Ace you stated above might be for GT-S5830. For the variants running the Broadcom BCM21553 the Odin version to use is v1.84. Odin v3.07 is more like a universal Odin that works on most devices.
Jarmezrocks said:
2). I am unable to get any detection with EFS pro and it returns no PIT file?
Click to expand...
Click to collapse
I don't know about this.
NightRaven49 said:
First off, wrong section.
Click to expand...
Click to collapse
Why? I was not actually asking for support as such, just sharing what I learnt/noticed.
NightRaven49 said:
1) We don't have a stable CM9 because our devs don't have the source code for all the drivers, not lack of RAM.
2) Have you formatted your system's partitions to the EXT4 filesystem? CM requires an EXT4 filesystem to operate.
Click to expand...
Click to collapse
Yes I am aware of that. I actually did attempt to flash the CM9 developer package several times all without result.
I tried many methods, firstly the conventional method and then several other unconventional methods. I first flashed CWM recovery 6.0.0.x (something around there) and that was ok but it could not detect the partitions....naturally I was on the standard firmware!
So I then flashed Thunder kernel which allowed recovery to see and mount all the partitions as well as prepare for a CM firmware flash. As I knew that CM required EXT4 I was prepared and flashed Rio's Ext4-RFS conversion script via Aroma in recovery. This worked very well. Only issue was that in doing so it corrupts the system partition and then I am unable to mount it anymore to flash CM.
Returning to stock or even attempting a nandroid restore from this point forward was fruitless as you can imagine. I tried several other combinations before retiring the idea. These included full system wipe after flashing CWM recovery (I figured maybe having data on the partitions its self could be interferring with the EXT conversion scripts? Everything seemed fine and ran correctly as expected only no system mounting.
I tried another method of flashing a ROM that included a kernel with it based on CM7 in the hopes that migrating to CM9 would be easier; this was not the case.
I picked a CM7 ROM that had a conversion script built in for BML to MTD. After returning to stock base via Odin I proceeded to flash recovery 6.0.0.x again, then I immediately flashed CM7 in the hope that I would kill two birds with 1 stone and have CM do its conversion on the fly as well as install (alleviating the need for mounting system after migrating to Ext4). This ROM installed without fault. All was well until I rebooted expecting to boot into CM7....this wasn't the case, I received bootloops like crazy. Naturally I booted into recovery (the ROM had downgraded me to version 5.x CWM recovery - that is fine anyway); I proceeded by clearing the caches and performing a factory reset (note This usually a good thing to do anyway regardless if you came from a clean reset factory firmware or not).
After doing this and rebooting the device reboots continuously as it did prior. I again decided to re-install the same zip as I am aware with changing to CM on many other devices it can sometimes require flashing 2-3 (and sometimes even 4) times for a firmware update to stick. Again still no response and forever bootloops. I decided at this point that if I was to waste the time and effort in Odin'ing back to stock AND THEN flashing my standard firmware that I should try another CM ROM.
I had CM9 available and even though half hour prior I was unable to mount the the system partition, I thought maybe that CM7 had been flashed first so if CM9 can see and mount partitions (like it should have originally) then I could flash CM9 in a hope that it might wipe out what ever was causing all the issues with bootloops.
CM9 installed correctly, however again I could not boot the device at all! I had read a post from a forum member's guide saying that if I got some of these issues that I should flash back to base and try it again. I did this another 3-4,5 times at least, various combinations of wiping base firmware, not wiping base firmware, wiping CM7; not wiping CM7......Always the end result = bootloops.
As you can imagine it was rather annoying if I was returning to base firmware (if I wanted to be stock carrier branded again I needed to flash twice, once to return to stock and again to flash Optus firmware.
Overall I was unable to get any firmware booting besides that which was provided as an Odin package AKA stock firmware. If I flashed a custom recovery over stock firmware I was unable to boot again. Oddly enough I found a standalone version of CWM recovery version 5 that was not CM specific and I performed a backup as it was able to see the stock partitions without throwing errors.
I then opted to do a conversion to EXT4 again and hoped that I could just restore my nandroid backup of the stock partitions like recommended in may of the guides for Galaxy Ace.
Unfortunately again I was unable to boot and the partitions become unmountable leading to yet again flashing back to base unbranded, then flashing stock carrier branded firmware (this has the correct modem for the carrier and region).
At this point I retired the idea of custom firmware. I will later root the device and just leave it on 2.3.7 and do internal/external SDcard swap and flash a theme and maybe a few compatible APKs from newer stock firmwares (at least ICS) to achieve the functionality I was hoping to have by flashing and using ICS. I found the best and most simplest way of achieving this was through Moto-Chopper Root method and adb, most of the documented ways of achieving root on the Ace don't work for the S5830V for some reason. So I will stick with what works.
NightRaven49 said:
The tar.md5 file has to split into the PDA, CSC, Modem and PIT files using Odinatrix. Search for it.
Click to expand...
Click to collapse
Thanks for the tip. :good: I have downloaded this ready now, so I will investigate how this goes? It looks very similar to a application I already use TAR.MD5_PACKAGER however I see it has an option for extracting from .tar.md5 files that have malformed header information. So that sounds like it should do the trick!:fingers-crossed: Do you think that this is maybe intensional as a means of stopping people like us from building custom firmware packages?
I mean the .tar.md5 package flashes perfectly as it should do which is very surprising seeming .md5 signature is very easily broken when you rename the file and you have not even opened it. That was what lead me to flashing it in the first place, I mean I figured that if the .tar.md5 was so corrupt as I believed it was, then the worst that can happen will be Odin will spit an error message and not proceed i.e. it won't even attempt to flash the said firmware!
Myself if I download any firmware that doesn't flash and fails due to md5 error, I immediately open it up and inspect it and unless it was extremely difficult to obtain (I have waited close to 30 hours once for an old firmware package to download from the only source I could find - but regardless if it was damaged or not I only wanted the old bootloader so I could integrate it into a new firmware package so the passing md5 was relatively unimportant), I would just re-download it again.
The fact that ALL of these packages for S5830I are like this (regardless of what browser or means I downloaded the package) and the fact that they DO in fact flash like normal packages, and the phone returns to 100% factory condition; tells me that this does look like a means of discouraging custom firmware developers? hmmm
NightRaven49 said:
The Odin specific for Ace you stated above might be for GT-S5830. For the variants running the Broadcom BCM21553 the Odin version to use is v1.84. Odin v3.07 is more like a universal Odin that works on most devices.
Click to expand...
Click to collapse
The device is actually a S5830V...the V devices are relatively undocumented, but they are essentially just the same as the more common i/M variants. I did my homework first with this, and I can most certainly attest that it is NOT the S5830. I wouldn't attempt flashing S5830 firmware, also S5830i firmware boots and functions as normal and has signal albeit not so strong when the modem is not for our carrier and/or region, but function none the less.
NightRaven49 said:
I don't know about this.
Click to expand...
Click to collapse
Well give the fact that I had performed so many download of firmware that I initially believed to be corrupt I was unable to extract the PIT (or in the case of the generic Ace OPS file) from the firmwares.
Being the fact that there was little known about the S5830V I was unsure if to proceed of not? There are few reports on the device and most of them were of owners bricking their device, only 1 report I know of where a V owner claimed he flashed S5830i firmware without a hitch, again he was not from Australia where I am from, so I was flying blind and scared I was going to brick the device.
At the very least if I had a PIT file I could analyse it and could manually make image backup of the EFS/IMEI partition straight after rooting the phone. I have looked already at scripts that scan the whole emmc and I hit a snag when the kernel I am using is not insecure i.e. adb cannot run as root. I have root and confirmed with root checker app but terminal emulator and/or command line are unable to obtain root
Anyway to shed some light for you EFS Pro is a means of doing this that works on most Samsung devices....just not the Ace as far as I can tell.
Yes I am already aware that there is Galaxy Toolbox and I had actually gone ahead and done all that already,but an incident more recently where I had a device I was repairing with a wiped IMEI and it actually refused to boot. This becomes a hassle when restoring the IMEI cause in order to have Galaxy Toolbox you need to be booted and rooted. I wasted a whole day repairing the IMEI. So pretty much the message here is what good is Galaxy Toolbox to me restoring the IMEI if it can't boot? NONE!
I contacted the developer weeks ago and explained my situation and he is still yet to respond. I explained that I had a V variant of the Ace and wanted to ensure I had all bases covered. I requested information on how I could open the IMEI manually outside of the Galaxy Toolbox in the case that it would not boot (as this was how I restored the other device last week and it worked), unfortunately I am still yet to hear a response form him? Slack.
When I obtain this information I will share it here on XDA in the hopes that people in Australia with this variant will search and find some info on it. This is also why I am making this post here so detailed for folks like me who have been searching fruitlessly for answers.
My thoughts are that maybe there is something still not 100% the same between the i and the V because all custom firmwares I tried made for the S5830i never worked?
There is maybe an issue with how they are scripting their installs that is causing issues, but it is worrying enough that flashing so far has lead to partitions becoming corrupted very easily. I have had this before with my own phone more recently because a dev made a simple mistake in an updater script that called an explicit partition by mounting point ID and not by a more generic mounting point like "/system", "system" which lead to lost IMEI and bricked phone.
I am not blaming the dev though because it is easy to assume that a even though the mounting was non-specific for my device and the partition being called was not actually the EFS, it should not have corrupted my EFS....but that is not true, so a discovery was made and a lesson learned from all this. I managed to revive my device and it lived to fight another day, but simple mistakes made in ignorance or lack of information can still be costly mistakes. Need I say more.
I will report back when I have got a proper partition map for the S5830V and all will be happy days
I don't feel like quoting anymore, but I do spot some anomalies.
1) ...we don't have CWM 6.0.0.x. Are you sure you used the 5830i CWM, not the 5830?
2) I was referring to some other version of Odin when you said the Odin version specific to Ace. Which version were you using then?
3) I don't see how rio's multi-formatter can render the system partitions unmountable. In that case try lopicl.00's EXT4 formatter. Go search for it. After formatting flash Biel's Specific Basic kernel.
also you were asking a question, so naturally this should be in Q&A.
Hello!
It seems like I am one of the few people to have a RS987 variant of the V10. I love everything about this phone, but it's killing me not having root access. I've avoided making a topic dedicated to this variant by posting in other threads and PMing people, but I've gotten nowhere.
I'm unable to unlock the bootloader like the T-Mobile variant even though I have to ability to enable "OEM Unlock" in the dev settings, and I've attempted to flash the Verizon VS990 5.1.1 KDZ to my phone in hopes I could root it after flashing it but it failed.
I'm willing to donate $40 to anybody that can provide a root method for RS987 variant of the V10.
Check this out.
http://forum.xda-developers.com/lg-...d-lollipop-kdz-10c-lg-servers-t3332348/page15
First post last link.
SoulAce1290 said:
Check this out.
http://forum.xda-developers.com/lg-...d-lollipop-kdz-10c-lg-servers-t3332348/page15
First post last link.
Click to expand...
Click to collapse
This just the KDZ for stock 5.1.1, which I provided
I should have posted this earlier but I was kind of busy IRL...
Anyway, it should be noted that I DO NOT have an RS987, therefore THIS HAS NOT BEEN TESTED! The usual disclaimers about voiding your warrenty, bricking your device, killing your cat ...etc applys.
Basically, flash
https://mega.nz/#!8k1UyCyC!Z2NIKvNOEkXBiElMLrXkv0RyPKhCN2q0KvlI1OH6ImY
this DZ file with
https://mega.nz/#!xgMgBIQD!VHtXeIlzpPydKRICtGfBUjXvtdN-KNtqX6U9bu3bY8Y
this DLL in LGUP.
I did not modify anything except /system, so theoretically you should be able to flash back the stock KDZ in download mode even if you experience bootloops.
Succeeded in flashing out.dz ... but
I succeeded in flashing the provided out.dz with LGUP, however, the phone would stall at initial LG logo, and wouldn't make the startup sound or animation.
Flashing back to the stock image for the RS987 worked fine, however. Even the carrier settings stayed.
A this point I can't verify if the bootloader is locked or not, I can't get into fastboot, just LG Download mode. Of course I'd be able to easily enable fastboot if I had root by writing zero's to the LAF partition. Ugh catch 22.
I also tried flashing the VS990 image for verizon pre-rooted system... no luck, LGUP refuses since it's not the same model number. I have a pre-rooted system.img file that I created using the extracted system.img from the stock .kdz. But I have not way to re-pack it into a .kdz or .dz file. Of course, I don't know if my rooted system image would work, since I can't test it.
Love the phone, but I'm so sick of Androids being locked down so tight.
WillyPillow said:
I should have posted this earlier but I was kind of busy IRL...
Anyway, it should be noted that I DO NOT have an RS987, therefore THIS HAS NOT BEEN TESTED! The usual disclaimers about voiding your warrenty, bricking your device, killing your cat ...etc applys.
Basically, flash
LINK REMOVED
this DZ file with
LINK REMOVED
this DLL in LGUP.
I did not modify anything except /system, so theoretically you should be able to flash back the stock KDZ in download mode even if you experience bootloops.
Click to expand...
Click to collapse
joatamonk said:
I succeeded in flashing the provided out.dz with LGUP, however, the phone would stall at initial LG logo, and wouldn't make the startup sound or animation.
Flashing back to the stock image for the RS987 worked fine, however. Even the carrier settings stayed.
A this point I can't verify if the bootloader is locked or not, I can't get into fastboot, just LG Download mode. Of course I'd be able to easily enable fastboot if I had root by writing zero's to the LAF partition. Ugh catch 22.
I also tried flashing the VS990 image for verizon pre-rooted system... no luck, LGUP refuses since it's not the same model number. I have a pre-rooted system.img file that I created using the extracted system.img from the stock .kdz. But I have not way to re-pack it into a .kdz or .dz file. Of course, I don't know if my rooted system image would work, since I can't test it.
Love the phone, but I'm so sick of Androids being locked down so tight.
Click to expand...
Click to collapse
Sorry about that. Too bad I don't have an RS987 to debug the issues. How about you send me your img file and I'll try to pack it for you?
I don't think the bootloader is unlocked for the variants except H960A and the T-Mo one. Also, you can view the bootloader status under the hidden menu.
Pre-rooted system.img file for RS987 LG V10
WillyPillow said:
Sorry about that. Too bad I don't have an RS987 to debug the issues. How about you send me your img file and I'll try to pack it for you?
I don't think the bootloader is unlocked for the variants except H960A and the T-Mo one. Also, you can view the bootloader status under the hidden menu.
Click to expand...
Click to collapse
WillyPillow, thank you for the offer to attempt to repack this system.img file into a .DZ file that'd be flashable to the LG V10 RS987...
I've PM'd you a link to a Google Drive with the rooted system.img
One file is system.rar and has a rooted system.img file that works with the RS987 LG V10.
The other file is RS98711a_02_0309.rar which is where I extracted the stock system.img file from. It was a multi-part system.bin file which I extracted and merged with "WindowsLGFirmwareExtractor".
I used the imgrooter script that worked for rooting my LG G4 phone which also had the same version of Lollipop 5.1.1. With LG G4 I was able to flash the file from download mode by opening a shell prompt with the phone using Send_Command.exe ... I was able to get Send_Command.exe to work with the LG V10, by first unlocking the mode by beginning to flash a .KDZ file and then unplugging the USB cable at the 9% progress mark. At this point I had a shell prompt with the phone. HOWEVER, I had extremely limited commands available. I could list files/folders, and run CAT on any file I wanted, but the command for dd or chmod or chown would all crash my shell prompt with the error "Hello I am LAF nice to meet you." At that point all commands with the phone would cease and go back to displaying "FAIL" for any command. (Really strange. I wish LAF would give me DD command from that shell prompt and I'd tell it where to put my system.img file!)
So, good luck re-packing this system.img back into a .DZ file I can flash.
I'm sure myself and other RS987 owners who frequent this forum would love a pre-rooted flashable system image.
Thanks in advance for your efforts.
@joatamonk
I just remembered what the problem is. I forgot a critical step in making the DZ
Unfortunately, I'm a bit busy recently, and I might not be able to fix this until next week. Sorry to keep you waiting.
joatamonk said:
WillyPillow, thank you for the offer to attempt to repack this system.img file into a .DZ file that'd be flashable to the LG V10 RS987...
I've PM'd you a link to a Google Drive with the rooted system.img
One file is system.rar and has a rooted system.img file that works with the RS987 LG V10.
The other file is RS98711a_02_0309.rar which is where I extracted the stock system.img file from. It was a multi-part system.bin file which I extracted and merged with "WindowsLGFirmwareExtractor".
I used the imgrooter script that worked for rooting my LG G4 phone which also had the same version of Lollipop 5.1.1. With LG G4 I was able to flash the file from download mode by opening a shell prompt with the phone using Send_Command.exe ... I was able to get Send_Command.exe to work with the LG V10, by first unlocking the mode by beginning to flash a .KDZ file and then unplugging the USB cable at the 9% progress mark. At this point I had a shell prompt with the phone. HOWEVER, I had extremely limited commands available. I could list files/folders, and run CAT on any file I wanted, but the command for dd or chmod or chown would all crash my shell prompt with the error "Hello I am LAF nice to meet you." At that point all commands with the phone would cease and go back to displaying "FAIL" for any command. (Really strange. I wish LAF would give me DD command from that shell prompt and I'd tell it where to put my system.img file!)
So, good luck re-packing this system.img back into a .DZ file I can flash.
I'm sure myself and other RS987 owners who frequent this forum would love a pre-rooted flashable system image.
Thanks in advance for your efforts.
Click to expand...
Click to collapse
Sorry about the (extremely) late reply.
Here's the updated DZ:
https://mega.nz/#!VkFlGCRK!tNegI52h6aPNYU98pQ6RISmlr53ok57XHZvjIQZR4xM
Hope it works!
No luck
WillyPillow said:
Sorry about the (extremely) late reply.
Here's the updated DZ:
https://mega.nz/#!VkFlGCRK!tNegI52h6aPNYU98pQ6RISmlr53ok57XHZvjIQZR4xM
Hope it works!
Click to expand...
Click to collapse
I thank you greatly for your efforts, however this .dz file didn't work. It got farther than the last one you had made. After flashing it with LG UP 1.14 the phone would reboot, show the android guy (the one with a spinning gear in it's belly), that screen would stay for about 5 seconds, phone would restart again, and then get stuck on the initial LG power up screen, it never played the startup sound or showed the animated LG logo.
RS987 must be a little different than the Verizon version? Perhaps it only loads signed kernels, or signed images or something?
Is this .dz file made from the pre-rooted image I had uploaded? Is there software that can be used to pack .DZ files from the .img file? So that I can try different methods of rooting system.img and flashing that to the phone?
The good news is the phone works fine after I flashed the stock RS98712a file back to the phone.
Thank you again for your efforts, they're appreciated.
Joata
Subscribed
Hi guys,
After reading through many of the different guides here regarding how to enable different LTE bands (band 20 I'm interested in) I decided to give it a go on my new Note 4.
After some tinkering with the binary values etc from this guide here: https://forum.xda-developers.com/redmi-note/general/unlock-lte-bands-step-step-xiaomi-mi-t3084774
It did not seem to do anything since band 20 in the place I live is usually not that strong signal wise compared to band 3 and 7.
So I thought: "Yeah, I'll just disable the other 2 and see if the band 20 works". This was unsuccessful and after some more tinkering I managed to completely lock out the whole LTE functionality of my phone.
Even inserting the decimal value from before I started this is working.
Any ideas on how to do a reset of the LTE part of the modem? Tried flashing an updated baseband, but to no avail.
Try doing
Code:
fastboot erase modemst1
fastboot erase modemst2
and then flash following this guide.
Attention when flashing with MiFlash: in the lower part of the window you can choose different .bat files, choose the flash_factory.bat (or flash_all.bat if flash_factory.bat won't work). Don't choose any .bat with lock in the name or you'll re-lock the bootloader.
Hi,
Tried to erase the modems, but I'm getting "Error: This image isn't allow download) error.
Any tips on how to get that to work? Tried using the old Google trick, but did not find a good solution for that.
I got that error too while flashing the FSG partition in flash_factory.bat but I didn't investigate on the problem, just used another flash.bat.
I searched for this error, looks like it's present only on recent devices (Redmi Note 4 and Redmi 4 variants). Maybe it's a new kind of protection, some partitions become read-only when we unlock the bootloader, to preserve the phone functionality?
If that's the case, first flash flash_all_lock.bat, that will flash the MIUI ROM and relock the bootloader (possibly unlocking the protected partitions), then re-flash the same ROM but using the flash_factory.bat (that contains a couple of flashing commands not present in the other .bat files, including the erase modemst commands).
Then, you can also try flashing via fastboot also the persist.img, just to be sure
Code:
fastboot flash persist persist.img
(this is not present in any .bat file)
At last check if the phone is working, and then you can unlock the bootloader easily, without any wait.
EDIT: I'm wrong, you cannot use fastboot to flash when the bootloader is locked (even if the images are original from Xiaomi).
Only solution I can think about now is, while the bootloader is unlocked, you can try to access the blocked partitions with other tools like Flashify (like you did while damaging them).
Managed to get it working again, with a separate xqcn backup which I modded with the IMEI numbers from my own phone
Juji said:
Managed to get it working again, with a separate xqcn backup which I modded with the IMEI numbers from my own phone
Click to expand...
Click to collapse
Can you link to the qcn file? I'm facing a similar problem and I would need that file.
Excuse my beginner English.
Here you go: http://en.miui.com/thread-545300-1-1.html