Related
Dear Community,
I just joined the forums today but have done quite a bit of reading already, particularly about the upgrade to 2.3.5 i hope to carry out in the near future once i clear up just a few remaining points.
Just for the record: i have watched the introductory video prior to registration and am well informed concerning my duty to "search before asking". And while i have 'scoured' the forums for answers to every one of the questions i am about to ask, it could very well be that relevant information has eluded me by virtue of chance.
To a certain extent, these questions have in fact been answered to a certain extent already, however most have not been answered to a degree i consider sufficient before taking the plunge into firmware flashing. I therefore appreciate that to more experienced users my inquires might seem somewhat redundant. The most i can offer in return is to create an intelligible and clearly structured post that might serve to help others who find themselves in a situation similar to my own.
Here goes:
1. Frankenstein Firmwares: As the name would imply, these are custom ROM packages that are not official in the sense that they are not available through Samsung Kies (i.e. official channels), however they consist entirely of stock components. In other words, they are only considered custom because they are available in a particular configuration not officially sanctioned by Samsung and not available via their official channels.
Is this assessment correct?
2. Flashing via Odin vs. ClockWorkMod (CWM): To tell the truth, i am not sure to what extent these two are actually related. According to willk22's excellent FAQ CWM is " designed so that if the user messes up a ROM installation, they can recover their phone. CWM is a modified recovery installed into the recovery partition that allows advanced control over ROM recovery, installation and much more." According to this FAQ, it can also to "install a ROM contained inside a flashable .zip file."
Based on what i have been able to gather, ROM packages destined for flashing via ODIN cannot be flashed via CWM and vice versa. Just out of curiosity, when would i use CWM to install a ROM and when Odin? Is this left solely to the discretion of the developer? What are the major differences?
3. Frankenstein Firmwares vs. Carrier Specific vs. Country Specific: What i don't precisely understand in this regard is how the CSC (Consumer Software Customization) relates to the different ROM packages. For example:
Intratech, in his extremely helpful ROM thread offers a number of packages for download that are considered "multi-csc", meaning that by typing a certain key combination into my phone i can gain access to a 'hidden' menu which will allow to determine the CSC version. If i then select my carriers CSC, what would the exact difference be between a custom carrier firmware and the firmware with the specific carrier CSC selected?
4. Android 2.3.5 for SGS2: Assuming i want to install ('flash') the latest android firmware version containing Android 2.3.5 for my SGS2, which firmware would i be best advised to use? I assume that i would probably be most sensible to use Intratech's XWKI8 / XXKI3 / XXKI4 Frankenstein Firmwares. Assuming, however, that i live in Poland or the 'Nordic Countries' (for which an official 2.3.5 firmware already exists), would it then be more sensible to use the country specific firmware build?
5. GSM / 3G Issues: I read in a few individual posts that flashing a country specific firmware (e.g. Poland or Nordic Countries) could result in loss of 3G coverage or otherwise inhibit cellular service. Is there any truth to these rumors?
6. The Jig: I know what the USB Jig does (it is a physical piece of hardware used to reset the flash count of the SGS2 used in case the phone needs to be shipped to Samsung for maintenance) but i am not sure when exactly it needs to be used. For example, if i flash one of the firmware packages mentioned above (XWKI8 / XXKI3 / XXKI4), would i need to use a jig to reset my flash count to zero? Or does the use of a jig only matter when rooting a phone - rooting of course not being necessary for firmware flashing in this case - ?
Thats it for now. Thanks for bearing with me, and thanks in advance for reading my post.
HeroTwin
HeroTwin said:
Dear Community,
I just joined the forums today but have done quite a bit of reading already, particularly about the upgrade to 2.3.5 i hope to carry out in the near future once i clear up just a few remaining points.
Just for the record: i have watched the introductory video prior to registration and am well informed concerning my duty to "search before asking". And while i have 'scoured' the forums for answers to every one of the questions i am about to ask, it could very well be that relevant information has eluded me by virtue of chance.
To a certain extent, these questions have in fact been answered to a certain extent already, however most have not been answered to a degree i consider sufficient before taking the plunge into firmware flashing. I therefore appreciate that to more experienced users my inquires might seem somewhat redundant. The most i can offer in return is to create an intelligible and clearly structured post that might serve to help others who find themselves in a situation similar to my own.
Here goes:
1. Frankenstein Firmwares: As the name would imply, these are custom ROM packages that are not official in the sense that they are not available through Samsung Kies (i.e. official channels), however they consist entirely of stock components. In other words, they are only considered custom because they are available in a particular configuration not officially sanctioned by Samsung and not available via their official channels.
Is this assessment correct?
2. Flashing via Odin vs. ClockWorkMod (CWM): To tell the truth, i am not sure to what extent these two are actually related. According to willk22's excellent FAQ CWM is " designed so that if the user messes up a ROM installation, they can recover their phone. CWM is a modified recovery installed into the recovery partition that allows advanced control over ROM recovery, installation and much more." According to this FAQ, it can also to "install a ROM contained inside a flashable .zip file."
Based on what i have been able to gather, ROM packages destined for flashing via ODIN cannot be flashed via CWM and vice versa. Just out of curiosity, when would i use CWM to install a ROM and when Odin? Is this left solely to the discretion of the developer? What are the major differences?
3. Frankenstein Firmwares vs. Carrier Specific vs. Country Specific: What i don't precisely understand in this regard is how the CSC (Consumer Software Customization) relates to the different ROM packages. For example:
Intratech, in his extremely helpful ROM thread offers a number of packages for download that are considered "multi-csc", meaning that by typing a certain key combination into my phone i can gain access to a 'hidden' menu which will allow to determine the CSC version. If i then select my carriers CSC, what would the exact difference be between a custom carrier firmware and the firmware with the specific carrier CSC selected?
4. Android 2.3.5 for SGS2: Assuming i want to install ('flash') the latest android firmware version containing Android 2.3.5 for my SGS2, which firmware would i be best advised to use? I assume that i would probably be most sensible to use Intratech's XWKI8 / XXKI3 / XXKI4 Frankenstein Firmwares. Assuming, however, that i live in Poland or the 'Nordic Countries' (for which an official 2.3.5 firmware already exists), would it then be more sensible to use the country specific firmware build?
5. GSM / 3G Issues: I read in a few individual posts that flashing a country specific firmware (e.g. Poland or Nordic Countries) could result in loss of 3G coverage or otherwise inhibit cellular service. Is there any truth to these rumors?
Thats it for now. Thanks for bearing with me, and thanks in advance for reading my post.
HeroTwin
Click to expand...
Click to collapse
Lengthy post there bud. I will answer to the best as far as I know as I am not all clued up either.
Q1 - yes is is correct because of the demand of different modems and csc packages.
Q2 - as far as I know you use odin to flash stock roms and CWM to flash custom roms. however CWM has a few nice features like wipe battery stats and NANDbackup.
(Hope you read about usb jig to reset your counter after flashing for warranty reasons)
Q3 - I am in South Africa where 2.3.3 is available via kies and I flashed both XXKI3 and XWKI8 so it is not country specific. I am not too sure if it applies if your device is carrier branded and you would like to keep it that way then you have to flash official firmware in carrier firmware thread or wait for kies.
The csc is for specific network settings such as texts, mms and phone calls. People sometimes have the problem of calls not coming thru or not being able to send texts. By flashing the csc for your region solves this problem.
The loss of coverage is related to the csc is what I think. Once you flash your csc it should be solved. Not too sure though. Ask the pro's to confirm but I have not had issues. But because I am on csc of my region
1edge1 said:
Lengthy post there bud. I will answer to the best as far as I know as I am not all clued up either.
Click to expand...
Click to collapse
Yes; i might have been able to cut back on some things, but i also wanted this thread to be useful to people who find it through search so i decided it would be good to provide a bit of context.
1edge1 said:
The csc is for specific network settings such as texts, mms and phone calls. People sometimes have the problem of calls not coming thru or not being able to send texts. By flashing the csc for your region solves this problem.
Click to expand...
Click to collapse
That's the thing! There are CSC's for both regions and carriers. If i have the correct CSC of my region is that just as good as having the correct CSC of my carrier? I recently changed my CSC from my carrier specific to my region in order to get official updates faster and have not noticed any coverage issues whatsoever, so ive been wondering to what extent this makes any difference...
HeroTwin said:
Yes; i might have been able to cut back on some things, but i also wanted this thread to be useful to people who find it through search so i decided it would be good to provide a bit of context.
That's the thing! There are CSC's for both regions and carriers. If i have the correct CSC of my region is that just as good as having the correct CSC of my carrier? I recently changed my CSC from my carrier specific to my region in order to get official updates faster and have not noticed any coverage issues whatsoever, so ive been wondering to what extent this makes any difference...
Click to expand...
Click to collapse
If you have the csc for your region, it will automatically be able to detect your carrier's settings. The csc are for regions, not carriers. If you flashed your region. Your good to go
lets try to give you so clear answer to your questions.
1. frankenstein versions are not custom roms and not official roms, they are different generic files mixed togather to allow for customizable for different regions by flashing different csc. they can be seen by kies depending on which csc is used.
custom roms cannot be seen by kies as the extensive customization to the files has removed or altered certain checks used by kies to determine if it is upgradable.
2. flashing via odin is using tar files and can be done external without the phone working as you can enter download mode by using the external hardware buttons.
CWM is a modified file used on a rooted phone which gives you more access to the file structure of your phone so you can install certain files like apks seperately. ODin will not allow individual apks to be installed by themselves.
CWM uses zip files if you want to flash custom roms are the developers can in future upgrades just replace certain files and post them within hours but tar files take a little longer to make.
cwm uses stored files on your internal sd card to maker changes but odin uses external files that have to be downloaded to your computer.
you can use internet on your phone to download the files then uses cwm to flash them as zip files usually have the installer as part of the file..
odin files have to be downloaded to your pc and a special installer packager called odin or heimdall if you are using a linux based machine to flash them.
3. basically the difference is that frankenstein versions as explained earlier are generic versions and not carrier specic roms which can be adjusted through the uses of modems and csc.
modems supplied with carrier branded roms will not work in other regions as their mdems (radios) for different regions and countries.
csc does the same as the modem but is geared to the data end of the phone.
4. if you want to stay as close t stock as possible use frankenstein versions with the csc for your region amd you can use odin to flash it.
if you want custom roms follow the developers instructions and use cwm to flash it.
5. Yes the rumors are true, different regions use different modens (radio)
Thanks for the replies - i believe i am slowly starting to get my head around firmware flashing.
Just one more question:
modems supplied with carrier branded roms will not work in other regions as their mdems (radios) for different regions and countries.
csc does the same as the modem but is geared to the data end of the phone.
Click to expand...
Click to collapse
So this would mean, if i wanted to install Intratech's 2.3.5 Frnakenstein Firmware, that i would:
First: Flash the entire 2.3.5 standard package
Second: Flash one of the Multi-CSC packages that contains the necessary CSC for my region so that my network settings and mobile internet work properly.
Is this correct
What do i do about the modem/radio? I see that there is a special are where you can flash the the CSC in Odin, but there is not corresponding way to flash the modem. Will altering the CSC also change the necessary radio/modem settings?
Thanks again!
HeroTwin said:
Thanks for the replies - i believe i am slowly starting to get my head around firmware flashing.
Just one more question:
So this would mean, if i wanted to install Intratech's 2.3.5 Frnakenstein Firmware, that i would:
First: Flash the entire 2.3.5 standard package
Second: Flash one of the Multi-CSC packages that contains the necessary CSC for my region so that my network settings and mobile internet work properly.
Is this correct
What do i do about the modem/radio? I see that there is a special are where you can flash the the CSC in Odin, but there is not corresponding way to flash the modem. Will altering the CSC also change the necessary radio/modem settings?
Thanks again!
Click to expand...
Click to collapse
Yes, you are starting to understand the concept.
you can flash modems using phone section of odin.
Cosmic Blue said:
Yes, you are starting to understand the concept.
you can flash modems using phone section of odin.
Click to expand...
Click to collapse
OK..however the case with Intratech's packages seems to be that he only offers the CSC for download separately, whereas the 'Modem' is combined with the PDA and the CSC in one .TAR file, with the occasional exception for certain packages. I double checked the the Modem in the standard package is the correct one for my region anyway, so i wont even need to be flashing it fortunately.
Thanks again for the help!
modems can be downloaded separately if need or unzip the tar package into its seperate components depending on what you are trying to do.
You are fortunate that the rom suits your needs.
Cosmic Blue said:
modems can be downloaded separately if need or unzip the tar package into its seperate components depending on what you are trying to do.
You are fortunate that the rom suits your needs.
Click to expand...
Click to collapse
Yes, that is really quite lucky. I do have one question remaining however:
Will i need to reset my install counter with USB hardware jug after i upgrade my firmware using Intratech's packages?
Please note, i don't intend to root my phone - I just hope to upgrade the firmware.
Thanks again for all the great support!
Only if you plan on having some work done at a service centre otherwise do not worry about it. It has no effect on how your phone works.
Thanks!
I have successfully carried out the update and have made a small guide/FAQ detailing my experiences, which could be of use to other beginners who wish to flash their devices for the first time.
>>> Absolute Beginners Guide to Flashing Firmware to SGS2 via Odin
I really hope this guide can help others.
If there are any changes or modifications i should make, please just let me know!
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,
I have a Samsung Galaxy S2 (i9100P), originally on orange, but since then I've moved onto T-Mobile. I have been having problems with low signal and many callers complaining that they cannot clearly hear and the sound is cutting out on both sides. T-Mobile have given me a signal booster and although the signal strength has massively improved, I still have poor call quality
Now I could be wrong here, but I think the signal issues have started since I flashed the original orange fw with NeatRom v5.6.
From searching on my pc, I've found my original orange brand fw, which was: I9100PXXLSS_I9100PBVLS2_I9100PORALS6_HOME.tar
Now I want to keep Neatrom, but I want to flash the modem and baseband which are showing as I9100XXMS4 on neatrom....I believe these could be the problem. Where can I get the correct versions that correspond to my mobile and network (EE) and how do I correctly flash these?
Thanks!
Come on guys, someone must be able to help me pls? :crying:
Just flash xxlss baseband (if it was ur original fw) in phone category in odin...
Thanks for helping me dr droid. I'll be honest mate... I don't have a clue what to do.
1. Do you have a link to a step by step guide to flash the modem fw and/or baseband? Could you show me?
2. Where do i get the correct baseband file for t-mobile network?
wowandroid said:
Thanks for helping me dr droid. I'll be honest mate... I don't have a clue what to do.
1. Do you have a link to a step by step guide to flash the modem fw and/or baseband? Could you show me?
2. Where do i get the correct baseband file for t-mobile network?
Click to expand...
Click to collapse
Download the firmware (the actual one which u said was present since the beginning)
Open the fw package with winrar
U will see a modem.bin file
Extract it to a known location
Connect phone in Download mode.
Open odin
Click on phone tab and then select ur extracted modem.bin
Flash ...
doctor_droid said:
Download the firmware (the actual one which u said was present since the beginning)
Open the fw package with winrar
U will see a modem.bin file
Extract it to a known location
Connect phone in Download mode.
Open odin
Click on phone tab and then select ur extracted modem.bin
Flash ...
Click to expand...
Click to collapse
Thanks very much dr droid. The problem I have is that I've only got the original nandroid backup with the following files:-
boot.img
cache.img
data.img
nandroid.md5
system.img
I extracted these using yaffey, but there is no file called modem.bin. Could you please tell me where it is located?
If this is not possible, where can I download the original orange fw with the following details:-
(MODEL: GT-I9100P
ANDROID VERSION: 2.3.4
BASEBAND VERSION: I9100PBVKI2
KERNEL: [email protected] #2
BUILD NO: GINGERBREAD.BVKI3)
Nandroid backups don't include the modem. Download the entire rom from Samfirmware, extract the modem.bin from that, flash as previously instructed.
Thanks mistah.
I've just done that, but it seems that my mobile's fw does not exist on their site anymore:-
Model: GT-I9100P
Product Code: GT-I9100LKNORA
Hidswver: I9100PBVKI3/I9100PORAKI3/I9100PBVKI2/I9100PBVKI3
Filename: I9100PBVKI3_I9100PORAKI3_ORA.zip
File not found
Find the most recent firmware for your country/carrier, download it, extract the modem.bin from it, flash that. If you get no joy from that, try another modem from another rom for your country/carrier. Modems are cross-compatible between roms & don't need to be used with a rom that's the same Android version/whatever, E.G - you can use modems that came bundled with GB roms if you're currently running ICS or JB & vice versa, etc, etc. Basically you can use any modem for the I9100, though I wouldn't recommend using modems specified as being for the I9100T unless you've tried every other modem first as these are specifically 'tuned' for the I9100T/the networks of carriers which sold it.
If you find none of the modems bundled with stock roms released by your carrier work for you, you can either:-
A) Root your phone, and start flashing any CWM flashable modem you can get your hands on (there are dozens, obviously - one for each stock rom released by each carrier around the world, there will be several for each carrier at least). This will be easier than downloading several dozen roms & extracting the modem.bin for each if you do get to this stage
and/or
B) Service centre/local mobile repair shop, though I would be doing A & trying as many modems as I could find on here (you will find dozens with an XDA or Google search) before doing that given that involves parting company with money.
MistahBungle said:
Find the most recent firmware for your country/carrier, download it, extract the modem.bin from it, flash that. If you get no joy from that, try another modem from another rom for your country/carrier. Modems are cross-compatible between roms & don't need to be used with a rom that's the same Android version/whatever, E.G - you can use modems that came bundled with GB roms if you're currently running ICS or JB & vice versa, etc, etc. Basically you can use any modem for the I9100, though I wouldn't recommend using modems specified as being for the I9100T unless you've tried every other modem first as these are specifically 'tuned' for the I9100T/the networks of carriers which sold it.
If you find none of the modems bundled with stock roms released by your carrier work for you, you can either:-
A) Root your phone, and start flashing any CWM flashable modem you can get your hands on (there are dozens, obviously - one for each stock rom released by each carrier around the world, there will be several for each carrier at least). This will be easier than downloading several dozen roms & extracting the modem.bin for each if you do get to this stage
and/or
B) Service centre/local mobile repair shop, though I would be doing A & trying as many modems as I could find on here (you will find dozens with an XDA or Google search) before doing that given that involves parting company with money.
Click to expand...
Click to collapse
Thanks very much Mistah.
1. I've checked on Sammobile.com and there are new i9100P orange firmwares, but since I've now moved to t-mobile, can I still use these? Also does it matter if my phone is a "P" variant?
2. My phone is already rooted with NeatRom v5.6, so how do I:-
a. Backup the current modem incase I flash the wrong modem or mess up?
b. Flash the new modem?
OK...Some clear thinking required...
1) Basically you can use any modem for the I9100 (this includes the I9100P)
2) You can't back up a modem, or not easily at any rate. And you don't need to given how easy they are to flash. If you want to go back to a previous modem, simply re-flash it. If you don't have a copy of your current modem, you might want to find a copy of it somewhere before you go flashing something else (not sure why that would be important to you given your current modem is giving you no connectivity, but, anyways...).
3) CWM flashable modems are flashable in the same manner as any other mod/kernel/rom in CWM. You should already know how to flash stuff in CWM if you're running a custom rom, if you don't, you need to start doing some searching (and how did you get a custom rom on your phone if you didn't know how to flash with it ?).
Right. I've given you more than enough info & won't be posting further to this thread, this stuff is really very simple, and we have guides/tutorials (most of which are stickied near the top of the General section) you can read if you need further info, and everything you've asked can easily be found with a search.
Up to you now...
MistahBungle said:
OK...Some clear thinking required...
1) Basically you can use any modem for the I9100 (this includes the I9100P)
2) You can't back up a modem, or not easily at any rate. And you don't need to given how easy they are to flash. If you want to go back to a previous modem, simply re-flash it. If you don't have a copy of your current modem, you might want to find a copy of it somewhere before you go flashing something else (not sure why that would be important to you given your current modem is giving you no connectivity, but, anyways...).
3) CWM flashable modems are flashable in the same manner as any other mod/kernel/rom in CWM. You should already know how to flash stuff in CWM if you're running a custom rom, if you don't, you need to start doing some searching (and how did you get a custom rom on your phone if you didn't know how to flash with it ?).
Right. I've given you more than enough info & won't be posting further to this thread, this stuff is really very simple, and we have guides/tutorials (most of which are stickied near the top of the General section) you can read if you need further info, and everything you've asked can easily be found with a search.
Up to you now...
Click to expand...
Click to collapse
No worries mate. Thanks for your help and advice.
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.
[size=+2]As a convenience to the users here, I have created recovery-flashable versions of the SM-N900V (Verizon Samsung Galaxy Note 3) Stock ROMs from the following releases:[/size]
[size=+3]NC4 NJ6 NK1 OB6 OF1 PL1[/size]
These flashables are ONLY INTENDED FOR SM-N900V OWNERS WITH UNLOCKED BOOTLOADERS AND STANDALONE CUSTOM RECOVERIES.
These ROMS are NOT pre-rooted. You are responsible for doing that (flash a superSU .zip in the recovery following the ROM flash if you desire root). Or, use the custom recovery's offer to root for you.
These ROMs are NOT debloated. Almost all of the original bloat and crapware is enabled.
[size=+1]NOTE: Odin-flashable Modems are provided as separate downloads for those that want to mix-n-match.[/size]
[size=+2]::::: MODIFICATIONS FROM 100% STOCK:[/size]
A small number of preinstalled apps have been suppressed/frozen; specifically those involved in automatic recovery-partition regeneration, OTA, Knox, or carrier spyware. See notes at [*1]
Also, the following two "build.prop" properties were disabled:
Code:
ro.config.tima=0
ro.securestorage.support=false
This seems to produce more stable ROMs when bootloaders are mix-n-matched with different ROM versions.
A script is provided which allows reversal of all of the above modifications to produce a 100% stock ROM (should you want that). See the notes at [*3]
[size=+2]::::: DOWNLOADS:[/size]
ROMs - Courtesy of Androidfilehost.com
Flashable Modems - Courtesy of Androidfilehost.com
[size=+2]::::: INSTALLATION[/size]
- Wipe system, dalvik, cache, and data (do not wipe /data/media)
- Flash ROM
- (OPTIONAL: full stock behavior restore. See [*3] ) (if you don't understand what this is, don't do it.)
- (OPTIONAL: inject root using chainfire's flashable superSU .zip, or allow the custom recovery to inject root) See [*4]
These flashable .zip ROMs ONLY modify the "system" and "boot" partitions. No bootloader firmware, modem firmware, or recovery partitions are affected; nor are wipes performed on any other partitions.
A script is provided in /system/etc for the ROM suppressions to be completely reversed, resulting in an almost-identical-to-Odin-stock ROMs, including resumption of OTAs etc. [*2]
[size=+2]::::: FEEDBACK REQUESTED [/size]
Because of the bootloader firmware anti-rollback protections, it is impossible for me to test all combinations of bootloader vs. kernel+ROM versions. I am presently still on NC4 bootloader firmware and have run all of these on top of the NC4 bootloader (sometimes flashing the modem which matches the ROM version, sometimes not) If you use any of these with a unique combination of bootloader and kernel/ROM, please drop a success/failure report here. Make sure to report both the bootloader and modem firmware versions.
[size=+2]::::: APPLICATIONS (or, Why Would I Find These Useful)?[/size]
- You want to run a Rooted PL1 stock before a root method becomes available without flashing the PL1 bootloader firmware. Benefit of more security against malware, but all the flexibility of root.
- You want to work on attempting root exploits of the PL1 ROM/kernel without taking the plunge of potentially locking your device forever with an Odin full-PL1 stock flash. E.g., flash the PL1 stock ROM over prior bootloaders (NC4/NJ6/NK1/OB6/OF1). The device can be used as a daily driver while you test your code... assuming that it operates correctly (TESTERS WANTED!)
- You want to flash back to Stock "for a minute" to check something, but without having to completely backup, wipe the device, re-root, re-unlock the bootloader, re-install your custom recovery, and restore your "SD card" data.
- You want a ROM where GPS/NFC/BT "just works"
- You occasionally want to use those Samsung S-Pen or TouchWiz apps.
- You'd like to create your own version of debloated stock.
- You think you might have damaged your hardware doing something and want to "see if it still works on stock"
- You want to run a rooted-stock KitKat ROM despite the fact that your ROM will have giant gaping security holes in it (that can be elevated to root privilege from an app with absolutely zero Android privileges)
[size=+2]::::: FAQs[/size]
Q - I am going to sell/give away my device. Should I use this?
A - Probably not. Use Odin with a factory image instead. These flashes by themselves do not enforce consistent bootloader, modem, or recovery firmware.
Q - Why didn't you debloat XXX and YYY from these?
A - Laziness. And besides, everyone has a different idea of what "debloated" means. Moreover, I wanted something that could easily be toggled into a "100% stock" configuration.
Q - I flashed one of these ROMs and yet I still see the "Knox Warranty" message when I boot up. Are the boot images non-stock?
A0 - The boot images in these ROMs are pure stock, right from the Odin factory tar/.md5 blobs.
A1 - Does your bootloader version match the kernel/ROM version? At least with the NC4 bootloader, you get that message when booting any kernel which is not the NC4 Samsung kernel - even when they are validly signed Samsung kernels. So, the only time you do not get that warning message is when the boot image is unmodified AND it exactly matches the version of the bootloader. I suppose that is the same behavior for other bootloader versions. Sigh.
A2 - "Systemless" root injection modifies the boot partition. That certainly will break the signing as you have modified the original boot image.
There is a way to check to see if your boot image has been modified; here it is:
1) compute the md5sum of the "boot.img" file from the release
2) find out the size/byte length of the factory "boot.img" file ("ls -l boot.img")
3) dump the same number of bytes out of the boot partition and pipe those bytes into the "md5sum" utility:
Code:
dd if=/dev/block/platform/msm_sdcc.1/by-name/boot bs=FILELENGTH count=1 | md5sum
Q - I did the stock reversion process and I still have the "Custom" logo showing up on my phone during boot-up. Why?
A - Because you are using a custom recovery, or a kernel which is mismatched to the version of the bootloader firmware. These ROMs are intended for use with unlocked phones with a custom recovery in any event.
Q - I can't get Knox containers to work. Why?
A - Knox containers will not work on phones with a blown Knox Warranty flag. That's an irreversible change you made to your phone when you unlocked it and booted an unsigned kernel. Sorry.
[size=+2]::::: Revision History[/size]
0.95 remove umount /system at end of reversion script; undo Mobicore service suppression.
0.94 add ELM*{.apk|.odex|etc} to suppressions
0.93 correct chmod mode in restore script for bin/install-recovery.sh (PL1)
0.92 baseline
[size=+2]::::: FOOTNOTES[/size]
[*1] For example: bin/install-recovery.sh, LocalFOTA, SDM, Knox*, VMS, SysScope, et cetera. All the other commercial bloatware and Samsung apps remain. NOTE: because of the possiblity of running these kernels/ROMs on mis-matched bootloader(s) where TZ/Attribution failures could disable certain TrustZone capabilities, I have disabled the following properties in /system/build.prop:
ro.config.tima=0
ro.securestorage.support=false
These may be easily reversed and the device rebooted.
[*2] If you were returning to stock in order to sell or dispose the device, probably it is best to just use Odin with the factory images.
[*3] Using the custom recovery's Advanced->Terminal function, find the script name in /system/etc, i.e.
Code:
ls -l /system/etc/bftb0*
and then
Code:
. /system/etc/bftb0_README*
It is sort of unlikely that anyone would need to use this. It may even be the case that Verizon has stopped providing OTA updates on older releases anyway. But it's there if you want it.
If nothing else, this script is very easy to read and so it documents all the changes that make it slightly different from pure stock; if you want to reverse one particular suppression, just read through the script and perform those individual changes manually, and reboot.
[*4] Since about superSU 2.65, the SuperSU .zip installation method MODIFIES THE BOOT PARTITION! The same is true of "systemless" root installations performed by custom recoveries (e.g. TWRP). You need to be aware of this in one very particular application: Installing a new bootloader over the top of a pre-rooted ROM which has the stock kernel version matching the version of the to-be-installed bootloader/modem firmware.
Running twrp/developer mode (via the unlocked bootloader thread), s7 edge AryaMod rom, with NC4 modem.
Do I flash this via twrp or Odin to get on the PL1 modem?
I want to stay on aryamod. I just want to update my modem
@bftb0 Thank you for this thread Sir. You are always a missive help :good:
godrick15 said:
Running twrp/developer mode (via the unlocked bootloader thread), s7 edge AryaMod rom, with NC4 modem.
Do I flash this via twrp or Odin to get on the PL1 modem?
I want to stay on aryamod. I just want to update my modem
Click to expand...
Click to collapse
Then just flash the N900VVRSEPL1_Modem.tar.md5 modem using Odin. (In the AP slot)
The modems are in a separate folder titled "OdinFlashableModems"; they are meant to be flashed separately according to the whims of the user.**
**having said that - and to stay on topic (which is these Stock ROM flashables) - if any connectivity troubles are encountered, the first thing to be tried is matching the kernel version of the ROM with the same modem version. As in NC4 modem with NC4 kernel, OB6 modem with OB6 kernel, et cetera. Flash the ROM in TWRP, and the modem in Odin (I actually am right now going through a matrix of flashing tests; already it is clear that the NC4 modem can't be used with NJ6 or NK1 kernels, for instance.)
For these ROMs (discussed in the OP) it's probably a good practice to simply download both the ROM of a specific release and the matching modem and perform the first boot of the ROM with the releases paired together. After that folks should feel free to screw around with modems to their heart's content.
cheers
.
bftb0 said:
Then just flash the N900VVRSEPL1_Modem.tar.md5 modem using Odin. (In the AP slot)
The modems are in a separate folder titled "OdinFlashableModems"; they are meant to be flashed separately according to the whims of the user.**
**having said that - and to stay on topic (which is these Stock ROM flashables) - if any connectivity troubles are encountered, the first thing to be tried is matching the kernel version of the ROM with the same modem version. As in NC4 modem with NC4 kernel, OB6 modem with OB6 kernel, et cetera. Flash the ROM in TWRP, and the modem in Odin (I actually am right now going through a matrix of flashing tests; already it is clear that the NC4 modem can't be used with NJ6 or NK1 kernels, for instance.)
For these ROMs (discussed in the OP) it's probably a good practice to simply download both the ROM of a specific release and the matching modem and perform the first boot of the ROM with the releases paired together. After that folks should feel free to screw around with modems to their heart's content.
cheers
.
Click to expand...
Click to collapse
Flash modem from CP slot,
Power off phone, start Odin, turn on phone in download mode.. (vol. down + home + power) and then plug into computer. Hit Vol Up to switch into download mode. Wait for com: notification in Odin and hit Start in Odin.
The above is only for XXXmodem.tar.md5 files. For complete ROMs that also include modem, follow the same except flash from AP slot.
I don't know why, but booting from power off into download mode seems to insure modem only tars 'take'.
Sent from my SM-N900V using Tapatalk
@donc113
I'll admit that I've never come across an Odin guide of any technical depth. I've used both the AP and BL slots (not together) for bootloader firmware, and largely haven't had any major issues flashing modems in the AP slot.
I'm wondering if there is no other purpose for the "slots" other than to be able to sequentially flash firmware using multiple file sources "in a single go". (i.e., the slots are not functionally different from each other, and are mostly there because Samsung service centers have firmware files partitioned by BL/AP/CP/CSC functionality, and the "slots" simply remind their techs to "fill up all the slots" when a complete flash is necessary)
One thing that is certain is that having begun an Odin flash, you can hit the "reset" button in the application (after the phone issues a RESET), but you need to restart the phone again in Odin/Download mode to perform a second flashing operation. Thus (maybe?) the need for multiple slots if firmware is in multiple files?. I guess I could break up a factory image into multiple sets and experiment but that seems low on the priority totem pole right now.
roll your own Odin .md5 tarballs:
Code:
tar -H ustar -c -f Odin-flashable-XYZ.tar flle1 file2 [...fileN]
md5sum Odin-flashable-XYZ.tar >> Odin-flashable-XYZ.tar
mv Odin-flashable-XYZ.tar Odin-flashable-XYZ.tar.md5
bftb0 said:
@donc113
I'll admit that I've never come across an Odin guide of any technical depth. I've used both the AP and BL slots (not together) for bootloader firmware, and largely haven't had any major issues flashing modems in the AP slot.
I'm wondering if there is no other purpose for the "slots" other than to be able to sequentially flash firmware using multiple file sources "in a single go". (i.e., the slots are not functionally different from each other, and are mostly there because Samsung service centers have firmware files partitioned by BL/AP/CP/CSC functionality, and the "slots" simply remind their techs to "fill up all the slots" when a complete flash is necessary)
One thing that is certain is that having begun an Odin flash, you can hit the "reset" button in the application (after the phone issues a RESET), but you need to restart the phone again in Odin/Download mode to perform a second flashing operation. Thus (maybe?) the need for multiple slots if firmware is in multiple files?. I guess I could break up a factory image into multiple sets and experiment but that seems low on the priority totem pole right now.
roll your own Odin .md5 tarballs:
Code:
tar -H ustar -c -f Odin-flashable-XYZ.tar flle1 file2 [...fileN]
md5sum Odin-flashable-XYZ.tar >> Odin-flashable-XYZ.tar
mv Odin-flashable-XYZ.tar Odin-flashable-XYZ.tar.md5
Click to expand...
Click to collapse
The CP slot is also able to flash .bin files.
Sent from my SM-N900V using Tapatalk
Carrier unlocked
flashed rom .rebooted with t-mobile SIM, wih no option in setting to change APN
bftb0 said:
Then just flash the N900VVRSEPL1_Modem.tar.md5 modem using Odin. (In the AP slot)
The modems are in a separate folder titled "OdinFlashableModems"; they are meant to be flashed separately according to the whims of the user.**
**having said that - and to stay on topic (which is these Stock ROM flashables) - if any connectivity troubles are encountered, the first thing to be tried is matching the kernel version of the ROM with the same modem version. As in NC4 modem with NC4 kernel, OB6 modem with OB6 kernel, et cetera. Flash the ROM in TWRP, and the modem in Odin (I actually am right now going through a matrix of flashing tests; already it is clear that the NC4 modem can't be used with NJ6 or NK1 kernels, for instance.)
For these ROMs (discussed in the OP) it's probably a good practice to simply download both the ROM of a specific release and the matching modem and perform the first boot of the ROM with the releases paired together. After that folks should feel free to screw around with modems to their heart's content.
cheers
.
Click to expand...
Click to collapse
teeve said:
flashed rom .rebooted with t-mobile SIM, wih no option in setting to change APN
Click to expand...
Click to collapse
https://forum.xda-developers.com/showthread.php?t=2582747
Sent from my SM-N900V using Tapatalk
teeve said:
flashed rom .rebooted with t-mobile SIM, wih no option in setting to change APN
Click to expand...
Click to collapse
These are in fact Verizon Stock ROMs. If they were intended to be for multiple carriers (out of the box) they would not be in this specific forum, and I would have mentioned it.
That said, any hacks/mods that might have worked in the past on SM-N900V stock ROMs could be possible, with "some assembly required".
I don't have a T-mo SIM to test out the method described in the link @donc113 provided above. (I can tell you though that with a VZW SIM, on the PL1 ROM you only will see "LTE/CDMA" and "CDMA" under Settings->Mobile networks->Network mode. I suppose that could depend on what SIM was in when the phone booted, but I don't really know)
If you get it working, please file a success report. Don't forget to mention the version that you flashed - you omitted that in your Q.
cheers
unlocked Verizon Note 3 w/flashable "stock roms ?
bftb0 said:
These are in fact Verizon Stock ROMs. If they were intended to be for multiple carriers (out of the box) they would not be in this specific forum, and I would have mentioned it.
That said, any hacks/mods that might have worked in the past on SM-N900V stock ROMs could be possible, with "some assembly required".
I don't have a T-mo SIM to test out the method described in the link @donc113 provided above. (I can tell you though that with a VZW SIM, on the PL1 ROM you only will see "LTE/CDMA" and "CDMA" under Settings->Mobile networks->Network mode. I suppose that could depend on what SIM was in when the phone booted, but I don't really know)
If you get it working, please file a success report. Don't forget to mention the version that you flashed - you omitted that in your Q.
cheers
Click to expand...
Click to collapse
OF1. Will try the unlocked hack. Only have LTE/CDMA option as it stands.
Carrier unlocked
bftb0 said:
These are in fact Verizon Stock ROMs. If they were intended to be for multiple carriers (out of the box) they would not be in this specific forum, and I would have mentioned it.
That said, any hacks/mods that might have worked in the past on SM-N900V stock ROMs could be possible, with "some assembly required".
I don't have a T-mo SIM to test out the method described in the link @donc113 provided above. (I can tell you though that with a VZW SIM, on the PL1 ROM you only will see "LTE/CDMA" and "CDMA" under Settings->Mobile networks->Network mode. I suppose that could depend on what SIM was in when the phone booted, but I don't really know)
If you get it working, please file a success report. Don't forget to mention the version that you flashed - you omitted that in your Q.
cheers
Click to expand...
Click to collapse
I dont have a verizon SIM to try the method described in the link. But I flashed the OF1 modem, and when I first start the phone with the T-mobile SIM, it says T-mobile and there is signal bars - and then immediately the data connection goes away and the "not a verizon SIM" comes up:silly:
teeve said:
I dont have a verizon SIM to try the method described in the link. But I flashed the OF1 modem, and when I first start the phone with the T-mobile SIM, it says T-mobile and there is signal bars - and then immediately the data connection goes away and the "not a verizon SIM" comes up:silly:
Click to expand...
Click to collapse
I noticed after my initial reply that those instructions @donc113 referenced presumed there is a "global" mode toggle in the Settings menus, and that doesn't seem to be the case for OF1 (as you say) or PL1 (as I observed).
This isn't an area of expertise for me - I've always been on Verizon, so I never had much of a need to hack a phone to a new carrier. (I'd recommend that you have a complete backup of your EFS partition before you start messing around.) << read that part two or three times.
On PL1, there is this (needs to be executed as root if you don't start it from within an app such as "App Browser"):
Code:
am start -W -n com.test.LTEfunctionality/com.test.LTEfunctionality.LTEFunctionalityTest
And then scroll down to "LTE APN Setting". Hitting the "+" sign (upper right corner) allows you to add a new set of APN parameters. Thing is, I don't know if this is something that allows you to make only a temporary change or if they "stick" after you exit that activity.
There is a file in /efs (namely /efs/apn-changes.xml) which seems to hold APN configuration data, but I have no clue if that is consulted for configuration information, or merely a copy of data that really lives elsewhere.
If the phone isn't your daily driver, you could probably flash back to the NC4 ROM as an experiment to see if "Global" is still available in the settings menu. Not so much because you would want to use an old, insecure ROM, but just to see if you can successfully get it programmed to work with T-mobile for voice+data+sms+mms. At least if you figured out what the correct settings were supposed to be, you'd only be faced with where they are supposed to go in OF1/PL1 (Were you using this phone before on T-mobile? If so, what ROM?)
There's a ton of stuff under the hood with those hidden settings. Hundred if not thousands of tweakable parameters. (If you want your head to spin look under IMS Settings) I would be careful about randomly poking at things. Apparently there's a fair amount of stuff stored in NVRAM which has nothing to do with anything that gets flashed by Odin with factory images, so it is entirely possible to permanently mess up a phone if you aren't super careful about recording prior settings and watching every keystroke. Some of those "maintenance" menus seem to be really poorly programmed - not defensively - and you could make unintended changes simply by walking through a set of menu picks.
.
bftb0 said:
I noticed after my initial reply that those instructions @donc113 referenced presumed there is a "global" mode toggle in the Settings menus, and that doesn't seem to be the case for OF1 (as you say) or PL1 (as I observed).
This isn't an area of expertise for me - I've always been on Verizon, so I never had much of a need to hack a phone to a new carrier. (I'd recommend that you have a complete backup of your EFS partition before you start messing around.) << read that part two or three times.
On PL1, there is this (needs to be executed as root if you don't start it from within an app such as "App Browser"):
Code:
am start -W -n com.test.LTEfunctionality/com.test.LTEfunctionality.LTEFunctionalityTest
And then scroll down to "LTE APN Setting". Hitting the "+" sign (upper right corner) allows you to add a new set of APN parameters. Thing is, I don't know if this is something that allows you to make only a temporary change or if they "stick" after you exit that activity.
There is a file in /efs (namely /efs/apn-changes.xml) which seems to hold APN configuration data, but I have no clue if that is consulted for configuration information, or merely a copy of data that really lives elsewhere.
If the phone isn't your daily driver, you could probably flash back to the NC4 ROM as an experiment to see if "Global" is still available in the settings menu. Not so much because you would want to use an old, insecure ROM, but just to see if you can successfully get it programmed to work with T-mobile for voice+data+sms+mms. At least if you figured out what the correct settings were supposed to be, you'd only be faced with where they are supposed to go in OF1/PL1 (Were you using this phone before on T-mobile? If so, what ROM?)
There's a ton of stuff under the hood with those hidden settings. Hundred if not thousands of tweakable parameters. (If you want your head to spin look under IMS Settings) I would be careful about randomly poking at things. Apparently there's a fair amount of stuff stored in NVRAM which has nothing to do with anything that gets flashed by Odin with factory images, so it is entirely possible to permanently mess up a phone if you aren't super careful about recording prior settings and watching every keystroke. Some of those "maintenance" menus seem to be really poorly programmed - not defensively - and you could make unintended changes simply by walking through a set of menu picks.
.
Click to expand...
Click to collapse
I'm on Jasmine which is OF1 and I have a global mode selection.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Sent from my SM-N900V using Tapatalk
Took a look over in my AFH area at the file counts to see what the activity level was. (The Note 3 is an "old" device, 3 years is approximately infinitely old LOL)
Over 60 downloads of the ROMs (OF1 and PL1 mostly) and about the same count for modems.**
And yet not a single report here of something actually getting installed. I suppose (as XDA doesn't require a login) that lurkers vastly outnumber XDA contributors ???
Ahh, well; I put them up there so folks could use them. Hopefully that's the case.
** oddly, a fair number of downloads of the NC4 modem. No clue what that would mean.
.
I'm running into an error when flashing the ROM in TWRP:
Code:
This package is for device: SM-N900V,hltevzw; this device is hlte.
Updater process ended with ERROR: 7
Error installing zip file '/external_sd/ROM_STUFF/Roms/N900VVRSEPL1_flashable_OTAsuppressed_vo.95.zip'
Updating partition details...
...done
My phone is a N900V.
---------- Post added at 02:12 PM ---------- Previous post was at 01:29 PM ----------
*Update*
Nevermind, I managed to get it working by editing the \META-INF\com\google\android\updater-script, replacing all 'hltevzw' with 'hlte', and updating the zip.
pnuker said:
I'm running into an error when flashing the ROM in TWRP:
Code:
This package is for device: SM-N900V,hltevzw; this device is hlte.
Updater process ended with ERROR: 7
Error installing zip file '/external_sd/ROM_STUFF/Roms/N900VVRSEPL1_flashable_OTAsuppressed_vo.95.zip'
Updating partition details...
...done
My phone is a N900V.
---------- Post added at 02:12 PM ---------- Previous post was at 01:29 PM ----------
Nevermind, I managed to get it working by editing the \META-INF\com\google\android\updater-script, replacing all 'hltevzw' with 'hlte', and updating the zip.
Click to expand...
Click to collapse
Cool :good:
Just for info to anyone else that get that error:
Basically its an error you get if you are using the wrong twrp. In your case you are using an hlte recovery not N900V twrp recovery. But what you did will work :good:
Sczar said:
Just for info to anyone else that get that error:
Basically its an error you get if you are using the wrong twrp. In your case you are using an hlte recovery not N900V twrp recovery. But what you did will work :good:
Click to expand...
Click to collapse
^this.
The custom recoveries don't do any fancy hardware detection during the assert in
META-INF/com/google/android/update-script
; they merely check the value in the script against the property
ro.product.device
that is established by init from reading the /default.prop file when the recovery boots up. Wrong recovery? Wrong ro.product.device value.
The situation is somewhat muddled by virtue of the fact that there are ROMs that will install & run more or less correctly on multiple device types, so the devs either check for each compatible device in the assert statement in the update-script... or they simply omit the assert() in the script altogether.
Either of the latter can lead people to conclude that they installed the correct twrp version - "hey, I used it to install a new ROM and it worked."
I chose to use strict checking when I packaged these up.
In any event, here are the TWRP downloads for hltevzw
bftb0 said:
^this.
The custom recoveries don't do any fancy hardware detection during the assert in
META-INF/com/google/android/update-script
; they merely check the value in the script against the property
ro.product.device
that is established by init from reading the /default.prop file when the recovery boots up. Wrong recovery? Wrong ro.product.device value.
The situation is somewhat muddled by virtue of the fact that there are ROMs that will install & run more or less correctly on multiple device types, so the devs either check for each compatible device in the assert statement in the update-script... or they simply omit the assert() in the script altogether.
Either of the latter can lead people to conclude that they installed the correct twrp version - "hey, I used it to install a new ROM and it worked."
I chose to use strict checking when I packaged these up.
In any event, here are the TWRP downloads for hltevzw
Click to expand...
Click to collapse
this ^^
True. Its not a hardware detection. Its a command in the default.prop i was trying to simplify it as much as possible.
But as you explained in details ?
Thank you
bftb0 said:
In any event, here are the TWRP downloads for hltevzw
Click to expand...
Click to collapse
That is the TWRP I was using though (twrp-3.0.2-0-hltevzw-4.4)