I'm in for $25 if we can get hspa+ working on TMobile.
$50 if we can get hspa+ working on TMobile for both 1900Mhz (WCDMA) and 1700/2100Mhz (AWS).
I'll be switching to TMobile when my contact ends. They still have unlimited data.
Sent from my SCH-I535 using xda premium
---------- Post added at 08:43 PM ---------- Previous post was at 08:14 PM ----------
The VZW GS3 is capable of roaming on 800Mhz/900Mhz/1800Mhz/1900Mhz GSM and 2100Mhz WCDMA. As pointed out by newuser134, if we have the necessary hardware to receive 1900Mhz, it is possible that flashing another modem may allow us to gain the capability to run WCDMA hspa/hspa+ over 1900Mhz.
Might be a good idea to focus on some areas to start. WARNING, testing modems can result in a hard brick that is only recoverable by JTAG. As we find answers, we should post them in the opening post with links to the posts containing the results.
1) Find out whether or not all of our existing modems lack the ability to utilize hspa/hspa+ over 1900Mhz WCDMA (also verify the area the user tries the sim operates hspa/hspa+ on 1900Mhz WCDMA).
a) Try AT&T post paid sim using LF2 modem
b) Try AT&T post paid sim using LG1 modem
c) Try AT&T post paid sim using LG7 modem
2) Find out whether or not it is possible to flash a modem other than the Verizon released/leaked modems. This is more of a follow up bootloader investigation. I recommend those investigating this to look in the original bootloader unlock thread opened by Adam Outler in the Original Development Section.
a) Find someone with JTAG skills who would be willing to attempt to
i) hex edit an existing modem, changing some non-critical section (perhaps any padding that may exist at the end of the image). This would allow us to see whether or not secure boot checks the modem partition (unfortunately, it almost certainly does).
ii) flash an AT&T modem (will most likely fail due to a different hardware identifier and signature)
b) Investigate whether or not secure boot can be disabled (even if it involves a small hardware mod to accomplish it). The bootloader unlocking thread has a decent amount of info on this, but we still would need to research further.
c) Reverse the machine code of the modem image to ARM assembly and then to C using Ralekdev's method described in the bootloader unlocking thread. This could give us some info on how the secure boot chain is enforced.
Some background info...
1) We may need to change more than just the modem partition (mmcblk0p1) for 1900Mhz WCDMA to work. For example, the Synergy IMEI backup script saves backup copies of modemst1, modemst2, efs, fsg, and backup (mmcblk0p12, mmcblk0p13, mmcblk0p11, mmcblk0p21, and mmcblk0p20). Clearly some cellular related data is stored in these partitions. Flashing just the AT&T modem might not play nice with the related partitions (although I don't see this preventing a boot as these partitions are not part of the boot chain; more likely you would boot to no cellular connection).
2) The bootloader unlocking thread has a lot of info regarding the boot chain partition order. I could be wrong, but I believe the modem hands off control to executable code at a very specific location in the next partition in the boot chain (after loading the executable code to memory?). If this location differs between the AT&T and verizon phones, it could cause a hard brick (a jump to the wrong location). During the bootloader unlocking efforts, Ralekdev was able to reverse several verizon GS3 bootloader partition's machine code (1s and 0s) into arm assembly and then reverse them to C. Using his methodology, we may be able to see if the AT&T and VZW modems (mmcblk0p1) both jump to the same partition at the same location. This could help us to know if flashing the AT&T would definitely hard brick (this isn't the only way the AT&T modem could hard brick, but identifying one way could stop us before we did hard brick). This is tedious work and we would need a full dump from someone with an AT&T phone (mmcblk0p1,2,3,etc). The alternative would be someone with JTAG and brass ones just flashing the modem.
Also check this out http://forum.xda-developers.com/show...php?p=31705003
It is the full partition layout for a 32GB i535.
PS, I read through some of the bootloader unlocking thread again (brings back good memories). This post by Ralekdev
http://forum.xda-developers.com/show...php?p=30082055 may explain why flashing an AT&T modem might hard brick. The AT&T modem would need to have the same hardware identifier and signature as the VZW one for the msm8960 to hand over execution to it. I'm gonna take a wild guess that it doesn't. I believe Verizon's locked bootloader may have just struck again.
Our current bootloader unlocking method was achieved by flashing an unsecure aboot partition (mmcblk0p5). In English (lol), there are several partitions in the boot chain leading to the kernel. The last one is aboot. The one after aboot is the kernel or the recovery partition (depending on whether you are or are not booting to recovery). Each partition in the boot chain checks to see that the next one has the correct signature before handing over execution to it. The unsecure aboot partition we now use to "unlock the bootloader" doesn't enforce (or just doesn't check) the signature of the kernel partition. This is why we are able to run custom kernels not signed by Samsung.
However, the bootloader partitions earlier than aboot still enforce signature checking before handing off execution. The first signature checks are done in hard coded msm8960 firmware. Although I'm not 100% certain of this, I believe the modem partition signature is checked in hardware by the msm8960 prior to execution (it would be a poor security system if it wasn't). So, unless we had Samsung's i535 private key used to sign the modem partition (something that would take more time than the current age of the universe to brute force on the world's fastest supercomputers), the AT&T modem would fail the signature check and the boot process would stop there. The AT&T and TMobile variants (and sprint for that matter) don't have Qualcomm's Secure Boot enabled, so their modem partition isn't subject to a signature check and enforcement.
On the bright side, if we were able to find a way to run a custom (non-i535) modem partition, we would have discovered a true bootloader unlock at one of the lowest levels.
Before the unsecure aboot partition was leaked and the i535 community rejoiced, there was some talk about seeing whether or not a QFuse for secure boot had been blown (permanently enabling secure boot). I don't think we ever found out with 100% certainty whether or not it was. If it isn't, we might still be able to disable secure boot, but it may involve a small hardware modification (a pull up or pull down resistor on an msm8960 GPIO pin. Annoying (and would take quite a while to locate the right one), but not too crazy to do with guts and a decent soldering iron. A software method is definitely preferred, but when you get that low level, you are sometimes dealing with read only segments.
The phone does indeed do WCDMA on 2100, the question we all would like answered is what other bands is the phone capable of operating WCDMA on, and if it does have that hardware, we need to figure out what Verizon did to the software to have it disabled.
This is a great discussion, when we got the unsecure aboot a month ago, I thought of this same issue, because on phones like HTC, when you get S-off, the phone basically doesn't care what code you put on it, it just loads it (as long as it is executable code). However, we just created a "hole" in the signature check, as you said, the unsecure aboot is still signed with the right signature, it just doesn't check for more signatures after that point. I posted this question in a thread right at that point, I'll look for it, but I don't think anyone responded to it. To achieve a truly unlocked phone on the same level as the other carrier versions, the CPU secure boot needs to be disabled. That is why I was still bothered by "secure boot enabled" when you go into Odin mode. This is not to say that what the devs did wasn't unbelievable and we are still benefiting from the fruits of all their work on unlocking the bootloader, so we did reach that goal, but I'm just making an observation that to truly be able to flash any partition without worry of not making the hand-over to the next partition, secure boot needs to be disabled.
I did some work on Motorola 6811 micro controllers when I was in college, there were different versions, some were only test chips and thus programmable only once, using e-fuses, so I understand how incredibly stupid and annoying it would be if Verizon has blown the q-or e-fuses in everyone's I535, which we paid for just like those on other carrier networks, but we didn't get the same phone they did if this is in fact true. In the bootloader R&D thread, which is now closed, E.V.A and I shortly had a few posts about enabling the gpio pin to turn off secure boot, they were trying to figure out the right voltage for the pull up resistor source, I think it ended up being 3V or something like that (don't try it without doublechecking that), but apparently there was a different pin somewhere that grounded that gpio thru a FET transistor, so applying the pull up voltage didn't help. Another thought was that even though the q-fuse may not have been blown (I sure hope it wasn't), that the gpio was somehow pulled down internally through the chip inside with a weak ground (like a voltage divider), so a higher pull up current (bias) was needed to actually disable secure boot. Adam also mentioned that not all Samsung schematics are always correct, that even though the manual said a high is needed to disable secure boot, it may actually need to be grounded, so that it was internally pulled high, and that it needed to be grounded externally for it to work right. Another option would be that it's a combination of pins that need the right input, not just that one (I think it was q-fuse 6 or 7), so until the right voltage is applied to all those pins, secure boot won't get disabled.
This all assumes that he q-fuse isn't blown, so there is a way to disable secure boot. If it is blown, then it cannot be disabled. Then the only option would be to make a hybrid AT&T / VZW modem file that has the signature needed, but executes the same things as the AT&T modem, hence enabling the 1900 MHz band.
A final thought is that just like the original aboot never enforced security on the /system or /recovery partitions, maybe when secure boot is on, it enforces signature checks when they are in some partitions, but if the code in the specific partition doesn't ask for it, like the unsecure aboot now doesn't, maybe the modem isn't checked for signature, ad th modem doesn't check for signature when handing over to the next link in the boot chain. That's why I was saying we just need to do it, and have someone with jtag do it, so no one bricks their phone, but we get an answer to the question without making a mistake that can't be recovered from.
Your thoughts, and anyone else's, are greatly appreciated, and it would be great at this point, to continue on to tackle the issue of secure boot, and figure out what we can flash to this phone without bricking it.
We're not really trying to improve reception, we're trying to open some frequencies for gsm/wcdma that would make this phone fully functional on AT&T or T-Mobile, it wouldn't really change anything on Verizon and CDMA/LTE. It would just make this phone a true multi-network phone. Right now it can get "4G" data on gsm carriers overseas, but not on AT&T or T-Mobile, when we solve this problem, it will get 3G/4G data on ANY gsm network, even domestic ones. So you could take your phone to AT&T or T-Mobile and get service there.
Yes, like ac21365 said, this phone does in fact receive wcdma 2100, we're uncertain about wcdma 1900, and although it is highly unlikely that this one might be there, wcdma 1700 (AWS band). Here's the interesting part though, the chipset in this phone is identical to the one in the AT&T version, I747, that one has both 2100 and 1900 bands. Our Verizon phone also has ALL the gsm bands that the AT&T version has (gsm 850, 900, 1800 and 1900), so the 1900 band filter, antenna and amplifier is already there for gsm. If they wanted to save money, why not remove all the gsm stuff since this is a CDMA phone? At this point, it would be cheaper to leave all the hardware stuff on the phone the way it is and just make them all the same, rather than make multiple versions, which would actually be more expensive. It is strange that all the gsm/wcdma bands that Verizon needs for their overseas gsm roaming is there, but the only one that would le you ge AT&T's "4G", is disabled, even though the chipset is physically able to receive/handle it. So it makes no sense that to save money, they left wcdma 2100 fully capable on this phone, but removed wcdma 1900. It could very likely be disabled by Verizon's modem software. That's why we want to get to the bottom of it.