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.
Related
I understand that this may have been asked, and I've been looking at similar threads, but I'm having a hard time finding a direct answer, so I apologize.
I have some experience rooting with an Atrix, but I just got this phone two days ago, this morning I used the 1-click method from rootwhiz to install the ICS leak. No problems having it run at all. I need to know, directly, did this install change my bootloader and change the binary count? I can't remember if I saw anytime of yellow triangle as people talk about. If it changed the bootloader what is there a safe method to return to the older bootloaders, and or do I even need to do so to root and install other roms?
I know that the Atrix had some problems in terms of returning to prior versions of things, and in my research I haven't found a direct answer to this question too.
Basically, did my bootloader change? Can I root using the heimdall method I keep seeing about safely? What would be the best way to root and install custom roms, neglecting the binary counter if I can get a jig or something?
Forgive me again for asking, I just need to have better answers before I try anything.
Are you asking for info for your Atrix or SGS2 device?
Sorry, I am asking about the SGS2.
ds1904.ds said:
I understand that this may have been asked, and I've been looking at similar threads, but I'm having a hard time finding a direct answer, so I apologize.
I have some experience rooting with an Atrix, but I just got this phone two days ago, this morning I used the 1-click method from rootwhiz to install the ICS leak. No problems having it run at all. I need to know, directly, did this install change my bootloader and change the binary count? I can't remember if I saw anytime of yellow triangle as people talk about. If it changed the bootloader what is there a safe method to return to the older bootloaders, and or do I even need to do so to root and install other roms?
I know that the Atrix had some problems in terms of returning to prior versions of things, and in my research I haven't found a direct answer to this question too.
Basically, did my bootloader change? Can I root using the heimdall method I keep seeing about safely? What would be the best way to root and install custom roms, neglecting the binary counter if I can get a jig or something?
Forgive me again for asking, I just need to have better answers before I try anything.
Click to expand...
Click to collapse
If you used the 1-Click method, yes. Your bootloaders are changed. Wouldve been much better to use the Heimdall method or just root your phone then flash the Leak ROM that task650 and Fenny made. As far as reverting bootloaders to stock, thats out of my range of knowledge. Im sure there is a way to do it though.
EDIT: For rooting, best way is to be on stock 2.3.4 and use the Zergrush exploit.
I've seen you're using the past tense a lot, I thought you already DID.
Anyway, for rooting and installing custom ROM, follow this thread:
http://forum.xda-developers.com/showthread.php?t=1311081
I can't pinpoint exactly what to do since having no info.
Thanks for the answers so far, now that I know my bootloaders have been changed I need to figure out how to either change back / and how to safely root. I may just have to wait it out I think though, no problem with that really, working just fine now. And never use the alarm
For clarification, my rooting experience is limited to the Atrix, the SGS2 is new as of Monday, and I am having trouble sifting through information. What I've learned so far is that maybe it was a little hasty to install the ICS leak the way I did. Prior to the ICS leak there was nothing changed on the phone.
You're going to have to get some experience with ODIN. Here is the bootloader you'll want to flash back to, however, then you'll probably need to flash a kernel with CWM (clock work mod) and then boot into cwm to flash a rom such as Tasks stock ICS leak. http://forum.xda-developers.com/showthread.php?t=1316726
So if I follow correctly the ICS leak I installed added newer bootloaders that prevent jigging in the future if it was needed. My two options are apparently to use the method that bypasses the counter, which was posted, or to use ODIN and flash the older bootloader, but this can be dangerous if done incorrectly.
The danger of bricking scares me a little, but I successfully used RSD Lite to unlock the bootloader on my Atrix, don't know if it's similar. Perhaps I should take the Atrix and attempt to install an older bootloader on it to get a feel for things? I figure that it wouldn't make much of a difference however...
I figured out that even though I have a newer bootloader now I still have a 0 for the binary counter, as the leak is considered a samsung official release, of course I don't know how that would effect any given warranty.
So, I still feel that these following questions are unanswered, I apologize if I am not understanding correctly:
1. Is it safe for me to root with the heimdall method even with the newer bootloaders
2. Is it safe for me to install custom roms without reverting the bootloader, as long as I am using the bypass method to prevent my counter from changing?
3. What is the exact risk to flashing the older bootloader, and what precautions should I take before doing so? If I flash the older bootloader without reverting to stock firmware will that cause a brick? Or is the risk just associated with fudging up the process of the flash itself, and hoping that the connection doesn't get cut (on that note, the phone, usb cord, and computer I'm using are all less than 4 months old, so that risk doesn't concern me a whole lote).
Sorry if these are stupid questions, I hope I am asking good enough questions to help others out in the future
After some more reading, here's another question as well:
Does the SGS2 technically have an unlocked bootloader already? It just counts how many times you install non samsung firmware?
Also just so I know that I'm not wrong, are Kernal, Firmware, and "Roms" all the same thing? How can you tell if a "package" or "rom" comes with bootloaders, as this is something I apparently am supposed to avoid.
ds1904.ds said:
1. Is it safe for me to root with the heimdall method even with the newer bootloaders
Click to expand...
Click to collapse
Dont believe you can root since you already flashed it with ODIN 1-Click
ds1904.ds said:
2. Is it safe for me to install custom roms without reverting the bootloader, as long as I am using the bypass method to prevent my counter from changing?
Click to expand...
Click to collapse
You cannot install custom ROM's because you dont have CWM.
ds1904.ds said:
3. What is the exact risk to flashing the older bootloader, and what precautions should I take before doing so? If I flash the older bootloader without reverting to stock firmware will that cause a brick? Or is the risk just associated with fudging up the process of the flash itself, and hoping that the connection doesn't get cut (on that note, the phone, usb cord, and computer I'm using are all less than 4 months old, so that risk doesn't concern me a whole lot).
Click to expand...
Click to collapse
Really not sure on these questions. Any takers?
ds1904.ds said:
After some more reading, here's another question as well:
Does the SGS2 technically have an unlocked bootloader already? It just counts how many times you install non samsung firmware?
Click to expand...
Click to collapse
No; Only download mode (Odin/Heimdall) flashes trigger changes to the warning screen.
ds1904.ds said:
Also just so I know that I'm not wrong, are Kernal, Firmware, and "Roms" all the same thing? How can you tell if a "package" or "rom" comes with bootloaders, as this is something I apparently am supposed to avoid.
Click to expand...
Click to collapse
Kernel is a set of drivers that tells the hardware what to do. Firmware is like a new base. (XXLPQ, DXLP7 etc.) A ROM is the whole package.
Please if I missed anything or am incorrect about some/all of this, somebody correct me.
Okay I think I'm starting to figure this out. I downgraded to 2.3.4 using an unroot/stock method I found, using odin and it worked. It would not accept the OTA update however, but I believe this is due to the ULCL2 baseband? Someone correct me if I am wrong.
Now I am going to use method 2c found here:
http://forum.xda-developers.com/showthread.php?t=1311081
to root and restore to the other baseband, which also happens to be the one that's best for my area I believe. From there, I can install CWM using one of the 31-c methods, and use CWM to install custom roms as long as they don't have bootloaders, correct? Or does it not matter if the packages have bootloaders.
Someone correct me if I am wrong, I don't want to ruin anything here. I think it's safe to install the files that come from the 2c method but wont be doing anything else until I know it's safe.
ds1904.ds said:
Okay I think I'm starting to figure this out. I downgraded to 2.3.4 using an unroot/stock method I found, using odin and it worked. It would not accept the OTA update however, but I believe this is due to the ULCL2 baseband? Someone correct me if I am wrong.
Now I am going to use method 2c found here:
http://forum.xda-developers.com/showthread.php?t=1311081
to root and restore to the other baseband, which also happens to be the one that's best for my area I believe. From there, I can install CWM using one of the 31-c methods, and use CWM to install custom roms as long as they don't have bootloaders, correct? Or does it not matter if the packages have bootloaders.
Someone correct me if I am wrong, I don't want to ruin anything here. I think it's safe to install the files that come from the 2c method but wont be doing anything else until I know it's safe.
Click to expand...
Click to collapse
Should be fine. NONE of the ROMs you find on the I777 boards in Ported or Original will have bootloaders so no worries. And yes after root use Mobile ODIN to install a zImage which will give you CWM. Highly recommend Siyah 2.6.14. Please stick to just trying some GB ROM's and get the hang of making nandroids etc before moving on the ICS ROM's.
D3M3NT3D_L0RD said:
Should be fine. NONE of the ROMs you find on the I777 boards in Ported or Original will have bootloaders so no worries. And yes after root use Mobile ODIN to install a zImage which will give you CWM. Highly recommend Siyah 2.6.14. Please stick to just trying some GB ROM's and get the hang of making nandroids etc before moving on the ICS ROM's.
Click to expand...
Click to collapse
All I get is an apk file, I've been searching all night for a zimage... The file says i777 flashkernal, and it's just an .apk. Mobile Odin can't see it unless I name it zimage with no file extension. I tried that and it seemed like it was soft-bricked so I used odin on the PC to reflash the stock root think mentioned in the thread.
I was thinking of CM7 if it will work flashing as a zip from CWM, if I can get CWM on there that is.
ds1904.ds said:
All I get is an apk file, I've been searching all night for a zimage... The file says i777 flashkernal, and it's just an .apk. Mobile Odin can't see it unless I name it zimage with no file extension. I tried that and it seemed like it was soft-bricked so I used odin on the PC to reflash the stock root think mentioned in the thread.
I was thinking of CM7 if it will work flashing as a zip from CWM, if I can get CWM on there that is.
Click to expand...
Click to collapse
Where in the hell are you getting an apk from? If you dl Siyah or Entropy kernel, the zImage is in the zip. Pull that and put it on your SD card
I am interested because I was in your position. Did the ICS leak 1 day too early and lost root. So what method did you use to go back to GB? Did you have to flash a new bootloader or was that all done in one package? Was it Entropy's "return" method?
I was seeing if I can keep the ICS leak and root. A dev here advised that all I need to do is re-flash the zip filed ICS leak. However since I have no root, I can't CWM recovery...I don't know another method to flash the rooted ICS leak.
So I'm thinking I have to wait for an exploit, or flash back to an old GB, root, ensure I have CWM, nandroid (I nandroided my rooted GB before upgrading to ICS leak), then flash the zip ICS leak.
Does anyone else have alternatives?
ds1904.ds said:
Okay I think I'm starting to figure this out. I downgraded to 2.3.4 using an unroot/stock method I found, using odin and it worked. It would not accept the OTA update however, but I believe this is due to the ULCL2 baseband? Someone correct me if I am wrong.
Now I am going to use method 2c found here:
http://forum.xda-developers.com/showthread.php?t=1311081
to root and restore to the other baseband, which also happens to be the one that's best for my area I believe. From there, I can install CWM using one of the 31-c methods, and use CWM to install custom roms as long as they don't have bootloaders, correct? Or does it not matter if the packages have bootloaders.
Someone correct me if I am wrong, I don't want to ruin anything here. I think it's safe to install the files that come from the 2c method but wont be doing anything else until I know it's safe.
Click to expand...
Click to collapse
SMH...root is not needed for CWM... a custom kernel is
Pirateghost said:
SMH...root is not needed for CWM... a custom kernel is
Click to expand...
Click to collapse
True but to do it with Mobile ODIN you need root
ds1904.ds said:
After some more reading, here's another question as well:
Does the SGS2 technically have an unlocked bootloader already? It just counts how many times you install non samsung firmware?
Also just so I know that I'm not wrong, are Kernal, Firmware, and "Roms" all the same thing? How can you tell if a "package" or "rom" comes with bootloaders, as this is something I apparently am supposed to avoid.
Click to expand...
Click to collapse
"ROM" is an improper name for the firmware flashed to a phone. (the memory in question isn't read-only by any means. In Windows Mobile devices, you had to flash the firmware image all in one go - but on Android, /system contents can be modified on the fly as they're a normal file system.) garyd9 started a little crusade against the term ROM and I try to continue it (but I slip up sometimes).
Kernel contains the most basic low-level hardware drivers for a device. It's a small portion of the firmware for a phone. The remaining portion is the system partition - /system - kernel and /system together make a complete firmware package.
And you are correct - our bootloaders are fundamentally unlocked, the only code signing enforcement is the custom binary counter. It can be reset either with the jig or with TriangleAway (TriangleAway requires ICS)
Entropy512 said:
"ROM" is an improper name for the firmware flashed to a phone. (the memory in question isn't read-only by any means. In Windows Mobile devices, you had to flash the firmware image all in one go - but on Android, /system contents can be modified on the fly as they're a normal file system.) garyd9 started a little crusade against the term ROM and I try to continue it (but I slip up sometimes).
Kernel contains the most basic low-level hardware drivers for a device. It's a small portion of the firmware for a phone. The remaining portion is the system partition - /system - kernel and /system together make a complete firmware package.
And you are correct - our bootloaders are fundamentally unlocked, the only code signing enforcement is the custom binary counter. It can be reset either with the jig or with TriangleAway (TriangleAway requires ICS)
Click to expand...
Click to collapse
Glad you chimed in. I now feel stupid at my lack of knowledge
I almost think that the issue is that your "unzipping" the zip image files that you are downloading.
Why is it so important that you keep the phone in a reversable mode? Are you planning on returning it or perhaps selling it and do not want it to be known that you have flashed it?
Personally I am not knowledgeable enough to offer much advice, I just read the forums as most and try to put together the peices of information that fit my situation.
The Dev forum is by far the best place to look and get your questions answered and there are a bunch of guides on step by step processes. The only real advice I can give you is to google each term and understand what it is you need and then post your question.
I rooted my son's AT&T SGII, then flashed CyanogenMod 9 daily updated ROM and Google Market. Everything worked great, but by using CWM recovery the flash counter increased by 1 (then 2 on retry) and the splash screen has the GT-I9100 and warning triangle graphics. As this was expected, I didn't see any cause for alarm.
No cause because I have a micro USB Jig and expected to be able to use it to go into download mode in order to reset the counter and remove the warning triangle. BUT... It didn't work.
I know the jig is good because it still works on my personal I777; I even purposefully tripped the flash counter to check. No problem. Since both devices are identical models, both rev. 01, and are configured alike I cannot diagnose why the jig will not work on the second device.
The differences between the devices are time and place of purchase. I bought mine very soon after the original release date, in San Antonio, TX. My son bought his in D.C. earlier this month.
Can anyone tell me how the device purchased at a later date differs in either hardware or firmware from an earlier device? And if so, does that make the jig obsolete?
The flash counter code is contained in the secondary bootloader. It is possible that the secondary bootloader was flashed and updated to a version of the sbl that cripples the flash counter reset code. If that is the case, the only fix is to flash the original secondary bootloader back onto the phone. You can find the files in the Download Repository. See link in my signature. Please be sure that you understand the risks of flashing bootloaders if you choose to take this path.
creepyncrawly said:
The flash counter code is contained in the secondary bootloader. It is possible that the secondary bootloader was flashed and updated to a version of the sbl that cripples the flash counter reset code. If that is the case, the only fix is to flash the original secondary bootloader back onto the phone. You can find the files in the Download Repository. See link in my signature. Please be sure that you understand the risks of flashing bootloaders if you choose to take this path.
Click to expand...
Click to collapse
Creepyncrawly,
Thank you for the prompt reply and the suggested solution. I will do as you recommend and try to correct the secondary boot loader using the files in the download repository.
I have to admit I am puzzled, since I used exactly the same procedure to root and flash ROMs on both devices. The only difference in procedures was which daily update to CM9 I used to originally flash.
Once I complete the procedure I'll let you know how successful the fix proved to be.
I would check the package that you flashed to see what it contains. If it did indeed flash sbl.bin you will find that file in the package. Just open it up to see what it contains. I would do that before I flash the bootloader.
There is an app to reset the flash counter that works with ics based roms called triangle away in case you are interested.
http://forum.xda-developers.com/showthread.php?p=22463153#post22463153
Sent from my SGH-I777 using XDA Premium HD app
creepyncrawly said:
I would check the package that you flashed to see what it contains. If it did indeed flash sbl.bin you will find that file in the package. Just open it up to see what it contains. I would do that before I flash the bootloader.
Click to expand...
Click to collapse
creepyncrawly,
Did check the file to verify the sbl, but couldn't find anything that seemed pertinent. Due to time constraints (My son goes back to D.C. this morning) I went forward with flashing the tar in the download repository as you suggested.
All seems well; phone booted up as expected, and the startup screen displays the correct model number minus the warning triangle. I then rebooted into download and applied the jig to reset the 0din flash counter. Now just like new, with CM9 running strong.
Only troubling aspect is why there would be a difference in the results using the same configuration on two identical devices. I'll leave that for another day.
Thank you for your suggestion.
~ zancro
One if the updates from Samsung for the sgs 2 made jigs stop resetting the flash counter with an update to the secondary boot ladders. Reflashing the old bootloader should fix that. Funny that the fix is so easy isn't it?
Sent from my SGH-I777 using xda premium
A newly purchased GS2 might include updated bootloaders.
The UCKK6 leak included "jig-crippled" bootloaders.
The OTA didn't touch the bootloaders.
Factory-UCKK6 devices may contain the UCKK6 bootloaders.
TriangleAway will do the trick on ICS.
I'm currently running the OEM bootloader of XXALE8. I know there's probably a new boot loader available for my phone. Would I get any benefit out of upgrading the boot loader, or should I jsut leave it as it is? I highly doubt I will ever downgrade back to ICS, (or even JB at this point). Also, how would I go about upgrading my bootloader without flashing an OEM Samsung ROM?
Bootloader is closed source, we don't know what's inside but definitely updating bootloader from your current state is recommended, as XXELLA+ has Sudden Death fix and other improvements, even if bootloader is not running long, newer is usually better.
Bootloader is sboot.bin file, however there also exist other partitions, such as hidden, param or tz. I suggest updating your bootloader by flashing official firmware from sammobile through Odin, this way you're sure that all low-level partitions are fine.
Be aware that newer bootloaders have warranty indicator, so will show modified status at each boot if you have custom recovery or kernel.
If you regularly use download mode to flash then update to prevent SDS and wear of your nand memory, otherwise I'd leave it alone.
Sent from my GT-I9300 using Tapatalk
boomboomer said:
Be aware that newer bootloaders have warranty indicator, so will show modified status at each boot if you have custom recovery or kernel.
If you regularly use download mode to flash then update to prevent SDS and wear of your nand memory, otherwise I'd leave it alone.
Sent from my GT-I9300 using Tapatalk
Click to expand...
Click to collapse
That's not true, newer bootloaders will set flash counter to 1 if running custom kernel, however I have official system status with ArchiDroid, therefore I don't have red exclamation mark .
That's what I said. You must have stock kernel installed with your rom? Even repacking the stock kernel will increase flash counter on new bootloaders.
Sent from my GT-I9300 using Tapatalk
boomboomer said:
That's what I said. You must have stock kernel installed with your rom? Even repacking the stock kernel will increase flash counter on new bootloaders.
Sent from my GT-I9300 using Tapatalk
Click to expand...
Click to collapse
It will, but red exclamation mark is not based on flash counter, it's based on system status. Therefore you can have 1+ flash counter and no red exclamation mark even on custom roms (like I do).
JustArchi said:
Bootloader is closed source, we don't know what's inside but definitely updating bootloader from your current state is recommended, as XXELLA+ has Sudden Death fix and other improvements, even if bootloader is not running long, newer is usually better.
Bootloader is sboot.bin file, however there also exist other partitions, such as hidden, param or tz. I suggest updating your bootloader by flashing official firmware from sammobile through Odin, this way you're sure that all low-level partitions are fine.
Click to expand...
Click to collapse
Is there a way to do it without flashing the OEM Samsung firmware, or is that the only way?
k-semler said:
Is there a way to do it without flashing the OEM Samsung firmware, or is that the only way?
Click to expand...
Click to collapse
There is a way but I suggest to flash full Samsung rom through Odin.
Why is that besides initial partition table setting? As far as I know, mine aren't messed up at all. This is after flashing several modems, recoveries, ROM's and kernels. Or is there something about the bootloader that is special? What is the alternate method to do so?
Read archi's first post for why to flash full rom, alternative is though cwm (if you make zip file) but this carries most risk of bricking your phone.
I got it successfully updated to bootloader XXEMG5 that I got it from this post.
http://forum.xda-developers.com/showthread.php?t=2189063
Is this the latest bootloader available?
Oops. Double post.
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.
So, I cobbled together a (custom-recovery) flashable NC4 stock ROM.
I'm interested to find out whether it is possible to boot it successfully from later bootloader firmware - e.g. NK1, OB6, or OF1
(I'm still on NC4 bl and not planning on upgrading near term. It boots on NC4 bl but that's pretty obvious lol)
[size=+2]Q: Why would this be useful?
A: to provide a means for upgrading bootloader firmware without starting from scratch.[/size]
For instance, there are folks on OB6 firmware that would like to use a custom ROM that will only work on OF1 firmware. They can certainly start from scratch (backup and unload the entire device); an alternative would be to:
- Make a backup of an existing rooted ROM (that more than likely has a custom or modified boot image so is not bootable when the bootloader gets re-locked) using the currently-installed custom recovery (which will also be non-bootable under re-lock).
- Restore a (debloated) pure stock ROM w/ Samsung kernel. Root it with Towelroot (does not touch boot image)
- Flash replacement bootloader only in Odin. Locked bootloader = no custom recovery... but with a rooted stock ROM already in place with an unmodified stock kernel it can be immediately unlocked.
NC4 is easily rooted with Towelroot-v3 "on device". No need for PC drivers, online rooting tools with a separate PC, etc (e.g. as with Yemen rooting methods on OB6, OF1)
This approach in principle saves the need to backup everything up in the /sdcard - but you have to know in advance that the NC4 stock kernel and ROM can successfully be booted with later bootloaders.
So anyway, that's what I'm asking for help testing with - folks that are: (a) unlocked and (b) on NK1, OB6 or OF1 bootloader willing to try flashing a debloated NC4 Stock ROM using their existing custom recovery, and see if it boots, roots, and if root survives a single boot cycle.
Contact me via this thread or PM; I'll provide the flashable NC4 and the Towelroot .apk
.
my n900v came with 5.0 Of1 but i rooted, unlocked BL. installed twrp and flashfired NC4 tar minus recovery
runs smooth.I hate lollipop.lol
only bug is wifi password resets everytime i reboot
im curious as to why i have trouble running certain nc2/nc4 roms..some want to bootloop/freeze
baja,biggins,and objective rom
kernel issue maybe? or BL version
btw. i am rooted via towelroot v3
hotrod85z said:
my n900v came with 5.0 Of1 but i rooted, unlocked BL. installed twrp and flashfired NC4 tar minus recovery
runs smooth.I hate lollipop.lol
Click to expand...
Click to collapse
Thank you for posting that, very useful/helpful information to know.
Does Flashfire understand the Samsung "sparse" image format of the system.img.ext4 file inside the Stock (Odin) .md5 tarfile blob? Or maybe somebody else packaged up a "flashable .zip" of NC4?
hotrod85z said:
only bug is wifi password resets everytime i reboot
Click to expand...
Click to collapse
in /system/build.prop, set ro.securestorage.support=false and reboot. You might also want to set ro.config.tima=0 as well.
I suspect that mixing and matching Samsung kernels with bootloader versions breaks something in the TrustZone, and so secure containers and other sort-of-obscure security functions no longer work as the TZ smells something fishy. I am using a rooted PL1 rom on NC4 bl and it would spontaneously reboot (infrequently) until I made the above changes - it's been rock stable for about 4 days now. Why this works I can't really say - it's a "generation skipping" bootloader and stock rom combination - N* bootloader and P* ROM *
hotrod85z said:
im curious as to why i have trouble running certain nc2/nc4 roms..some want to bootloop/freeze
baja,biggins,and objective rom
kernel issue maybe? or BL version
btw. i am rooted via towelroot v3
Click to expand...
Click to collapse
all of the above or none of the above LOL
There are definitely some mysteries here, and I don't claim to fully understand the interdependence of the TZ (== bootloader firmware), the TIMA and RTKP stuff in the kernel, and the cross-communication between kernel and TZ via the qseecom service daemon (which is in the ROM in /system/bin) much less how the APIs of all these interfaces might have changed between major releases.
You could check those two build.prop settings in those ROMs for starters though. I suspect that if the TZ smells something fishy (e.g. a kernel TIMA to TZ info mismatch), a variety of secure credential services in the TZ stop working. It is possible that "ro.securestorage.support" is a toggle that attempts to use TZ services when it is set to "true", and so anything in the ROM which builds on it breaks because the TZ is refusing to play on an otherwise "stock" ROM variant.
FWIW I got the AryaMod (S7Edge MM port) + phantom kernel running on NC4 bl + OF1 modem for a full 24 hours after I disabled the qseecom service daemon. It ran long enough that I had customized the whole thing as a daily driver with all my apps, verified that all sensors & radios worked, made test calls, etc. Rebooted it and the kernel started getting reset by a "Modem Reset". Even weirder was that despite the use of the OF1 "modem" firmware, the kernel was reporting a bunch of RIL "unknown ioctl's". Strikes me as odd that the whole thing could run that long with so many different things happening, and then the "modem" is unhappy - even though other folks are using the ROM with OF1 bl + OF1 radio/modem firmware. (As if the "modem" isn't really the source of the problem, even though that's what initiates the device reset).
.
i initially tried flashing NC4 full tar via ODIN. but even bl unlocked. i got FAIL. flashfire worked!
very curious as to whether a custom n900v kernel would boot my 4.4.2 custom roms..its either that or the BL isnt compatible with non-touchwiz roms....
most of the kernel/modem/firmware links on here are 404 error dead links.. would be nice to see an up to date sticky. ill flash anything as long as i dont end up in JTAG mode with a brick.lol
ive played with verizon s5 atnt s2,galaxy capitivate,atrix 4g and many other phones
the s2 is still by far the fastest Smoothest phone on cm7..the newer the phones..the newer the OS..the bigger the resourse hogs"ram" im a minimalist...
even after flashing NC4 official full tar..im still showing OF1 baseband under settings
@hotrod85z
FWIW I posted a bunch of recovery-flashable stock ROMs here.
There is also a link in that thread to a complete set of (Odin flashable) modems for NC4, NJ6, NK1, OB6, OF1, and PL1 if that is of interest to you.
Maybe I wasn't paying attention, but I could swear that on at least one occasion or two when I performed an Odin modem flash, it didn't "stick", despite no complaints on the handset screen or in Odin - the next boot showed the (prior) baseband version, not what I flashed. Its a bit of a mystery to me; but for now I've resolved to make sure that after the Odin session is complete, I wait 30 seconds or so, then remove the USB cable, and then pull the battery rather than try to restart the device by holding buttons down. It is possible that those events occurred when I soft-restarted the phone, but I'm not sure. For now I'm just trying to always flash and restart with exactly the same method to avoid different behaviors from creeping in.
PS I have no idea if those ROM flashables are compatible with Flashfire. They might be, but I've never tested it, and as they are not pre-rooted I'm not going to suggest it for fear that somebody with a rooted but locked (bootloader) phone will try using flashfire and then end up with a phone that needs a full Odin re-install. Appearances are that each version of the bootloader restricts the Samsung signing verification to only the matching kernel version - you can't even boot a Signed samsung kernel on a locked phone if it is a different version than the bootloader's version.
Hello all I have a emmc exploit note 3 I'm using here and I wanted to flash different radios for the us carrier note 3's and I first tried to use flash fire to try to update the modem, but even that didn't stick, cause I don't readily have a pc available, I wasn't ballsy enough to flash a different carrier modem, since I checked the odin screen and saw that instead of a bootloader unlock, its in developer mode and I didn't want a brick, so overall my question is, do I need a unlocked bootloader to flash different modems and do I need odin tovdo it or will some sort of mobile odin or something do it? Thanks mates and happy flashing.
Dlind said:
Hello all I have a emmc exploit note 3 I'm using here and I wanted to flash different radios for the us carrier note 3's and I first tried to use flash fire to try to update the modem, but even that didn't stick, cause I don't readily have a pc available, I wasn't ballsy enough to flash a different carrier modem, since I checked the odin screen and saw that instead of a bootloader unlock, its in developer mode and I didn't want a brick, so overall my question is, do I need a unlocked bootloader to flash different modems and do I need odin tovdo it or will some sort of mobile odin or something do it? Thanks mates and happy flashing.
Click to expand...
Click to collapse
Well, your question is way off topic for this thread.
But since nobody is in here anyways, I guess I'll answer the parts that I am able to.
The modems that I posted over in that other thread were meant to be flashed in Odin using a PC. You can use either the AP slot or CP slot. Note that the very first post says - in big bold blue letters "Odin-flashable Modems".
Not flashfire. It never said anything about flashfire.
Is there such a thing as MobileOdin? If there is, I know nothing about it and certainly have never tested anything with it. So I don't know and am not going to speculate.
You said something confusing here:
Dlind said:
I checked the odin screen and saw that instead of a bootloader unlock, its in developer mode
Click to expand...
Click to collapse
If it says "MODE: Developer" you have an unlocked bootloader. Which is exactly the same thing as a Developer Edition phone.
If you were to use a PC with Odin and you flashed a FULL Stock firmware flash, yes it would overwrite the unlocked bootloader and indeed re-lock the phone. If you were able to re-root that (stock) ROM, you could perform the unlocking procedure again to unlock it.
On the other hand, those Odin-flashable modem packages do not contain the bootloader firmware, so if you were to use Odin on a PC to flash just those modem images, your bootloader would not get re-locked - the unlocked bootloader is still there, untouched.
When the carriers issue an OTA update, many times (perhaps most of the time) they contain a modem update (NON-HLOS.bin and modem.bin). So it is obvious that they are able to be flashed **somehow** right on the phone, without using Odin from the PC or an "Odin app" at all.
BUT that happens using a combination of the STOCK recovery and the bootloader itself during the reboot following the actions taken by the STOCK recovery. (My guess is that the recovery simply "stages" it into place, and sets some flags so that the bootloader knows that it is supposed to evaluate the crypto signatures of the file blobs that the recovery put into place and it is actually the bootloader that does the flashing. That's really not a whole lot different than what happens when you transfer files from Odin to the phone - the "Odin/Download" mode is just one of the personalities of the bootloader. (Odin is actually a rather dumb program - it's the bootloader on the phone that gets to decide whether a flash happens. It does that by carefully examining the file blob that gets transferred, e.g. crypto signature checks)
My guess is that you would be able to flash STOCK modem packages from Odin (using a PC) independent of whether the bootloader is locked or unlocked. But as I said: "guess".
I don't have a second phone to test with, so I would have to flash completely back to stock and lock my bootloader to be able to test that hypothesis. That's a big jobs because of all the crap I have to backup and restore to my phone.
Frankly, if you don't have access to a PC, and you really need your device to keep working, I would advise you to stop screwing around with it, simply because you don't have good tools available to fix it if a disaster occurs.
PS. I've never once noticed anything different between various radio firmwares on ANY device I've ever owned.
bftb0 said:
Well, your question is way off topic for this thread.
But since nobody is in here anyways, I guess I'll answer the parts that I am able to.
The modems that I posted over in that other thread were meant to be flashed in Odin using a PC. You can use either the AP slot or CP slot. Note that the very first post says - in big bold blue letters "Odin-flashable Modems".
Not flashfire. It never said anything about flashfire.
Is there such a thing as MobileOdin? If there is, I know nothing about it and certainly have never tested anything with it. So I don't know and am not going to speculate.
You said something confusing here:
If it says "MODE: Developer" you have an unlocked bootloader. Which is exactly the same thing as a Developer Edition phone.
If you were to use a PC with Odin and you flashed a FULL Stock firmware flash, yes it would overwrite the unlocked bootloader and indeed re-lock the phone. If you were able to re-root that (stock) ROM, you could perform the unlocking procedure again to unlock it.
On the other hand, those Odin-flashable modem packages do not contain the bootloader firmware, so if you were to use Odin on a PC to flash just those modem images, your bootloader would not get re-locked - the unlocked bootloader is still there, untouched.
When the carriers issue an OTA update, many times (perhaps most of the time) they contain a modem update (NON-HLOS.bin and modem.bin). So it is obvious that they are able to be flashed **somehow** right on the phone, without using Odin from the PC or an "Odin app" at all.
BUT that happens using a combination of the STOCK recovery and the bootloader itself during the reboot following the actions taken by the STOCK recovery. (My guess is that the recovery simply "stages" it into place, and sets some flags so that the bootloader knows that it is supposed to evaluate the crypto signatures of the file blobs that the recovery put into place and it is actually the bootloader that does the flashing. That's really not a whole lot different than what happens when you transfer files from Odin to the phone - the "Odin/Download" mode is just one of the personalities of the bootloader. (Odin is actually a rather dumb program - it's the bootloader on the phone that gets to decide whether a flash happens. It does that by carefully examining the file blob that gets transferred, e.g. crypto signature checks)
My guess is that you would be able to flash STOCK modem packages from Odin (using a PC) independent of whether the bootloader is locked or unlocked. But as I said: "guess".
I don't have a second phone to test with, so I would have to flash completely back to stock and lock my bootloader to be able to test that hypothesis. That's a big jobs because of all the crap I have to backup and restore to my phone.
Frankly, if you don't have access to a PC, and you really need your device to keep working, I would advise you to stop screwing around with it, simply because you don't have good tools available to fix it if a disaster occurs.
PS. I've never once noticed anything different between various radio firmwares on ANY device I've ever owned.
Click to expand...
Click to collapse
Thanks SOOOOOO MUCH for your input I kinda had a feeling that the idea was risky at first and I don't know a whole lot about odin and I wish Samsung could have created something much easier to use, but thanks for answering the wayyyyy off topic question, I'm gonna smash that thanks button, I'm also going to take the advise on not cross flashing different modems, its just to risky. You answered all my questions so thanks, Also I want to say thank you for your continued work on this phone is by normal terms "old" now but in reality its still an amazing phone with the right custom software, and happy flashing!