[Q] Do we have any part of the EA28 radio? - Fascinate Q&A, Help & Troubleshooting

I have read it implied that there is no real difference between the EA28 radio and the prior Di01 radio.
I know we do have the official ED01 ota update.zip as a manual download:
http://www.androidpolice.com/2011/0...te-froyo-update-starts-early-rolling-out-now/
That file includes a modem_delta.bin for taking the EA28 modem and updating it to ED01. It stands to reason that if we have enough examples of modem A, modem B, and modem_A_B_delta, we would be able to learn the delta mechanism and get our official ED01 modem.
Does anyone know any examples where we have the two official radios and the delta in between, or whether we have a matching binary for EA28 at least?
==============
Code:
package_extract_file("modem_delta.bin", "/tmp/modem_delta.bin")
write_firmware_image("/tmp/modem_delta.bin", "modem_delta.bin")
Actually I assumed incorrectly. Judging by the update script, modem_delta.bin is not just a delta of the actual modem.bin, but an executable that undoubtedly contains the diff and also contains the instructions to write to the radio. Still, if it's in there, it likely can be found.
Do we actually need ED01 modem.bin? Perhaps not, but it would be nice if we had at least some way to restore it without repeatedly downloading the EA28 update over the air.

Related

[Q] Will these roms get ride of CMW and allow the update?

I have been reading through the threads and was wondering if the ROM's listed in the following thread http://forum.xda-developers.com/showthread.php?t=842000&page=8# will not only take out Clockwork Mod but also allow for the new update to 4349? Does anyone know?
My understanding from all the threads, and mostly roebeet's comments is that you have to be on stock 3588 and with NO CWM, to safely upgrade to the new 4349 firmware (note I haven't taken the OTA yet, so take that with a grain of salt).
As far as the list of older stock versions, I think (not sure) that 3588 is the only one of those that overwrites CWM and replaces it with stock recovery.
There was another one, before 3588, that's not on that 1st post (see my signature - it was the one I had before 3588) that also replaced CWM with stock recovery.
Jim

[Q]Copy ROM/Radio from phone

Is it possible to copy from a new phone the ROM/Radio into a file or any other conveyance that would allow it to be flashed to another..
Reason behind this is, I can pickup Fascinates all day for pretty cheap and have them work on the local Verizon clone carrier if I can copy their radio. The guy at the place has the ROM but for some reason NOT the radio so he cant flash a Verizon version to their version.. In using what I know of the devices at the worst a dd if/of from various mmcblk devices might do it, but was wondering if any one has ever done this? If so I could root one of their stock devices copy the radio and thus they'd be able to program it to work with their 3G data service (Voice will work, data will not with out the radio as VZW locks them to their settings)
They do not care about ESN status or if its in their DB, so that part is taken care of.
Any info would be great.
Thanks!
1. Wrong Section.
2. You can dump the ROM, that is quite simple to do. However, you can't dump the radio. The only method we have to get the radio is to hope for a leaked Odin package from VZW or Samsung that has it. Samsung has protected their proprietary info in the bootloader and modem, so if you try to dump them, you get only a partial file. The most recent radios available are from DL09 and EB01 that can be flashed via Odin. EA28, ED01, and ED03 do not have modem files available.
Just use ec01.
Sent from my SCH-I500 using XDA App

PG58DIAG errors in bootloader

Hi, I've recently rooted my phone and I'm quite happily running InsertCoin ICS ROM. Although I don't have any problems I'm curious to know why when I reboot into the bootloader and select the BOOTLOADER option from the menu is get numerous errors/warnings saying can't find PG58DIAG.zip, PG58DIAG.nbh and a number of other files. Why is this happening, is it merely the bootloader looking for these files so it can update the firmware? I recall having to drop a pg58diag.zip file (I think it was called that anyway) as part of the rooting process.
Finally what do these files update, I understand it's firmware but is it specifically the radio firmware as I've seen various references to updating radio firmware specifically and other references to just firmware as if it applies to more than just the radio.
Sorry if these questions have been asked before but I want to be very clear on what files relate to what when upgrading and also the differences in process to simply flash a new ROM which so far seems dead easy - simply pick a zip file from the SD card within 4ext Recovery and follow the installation instructions. It's only when there are dependencies on other files (such as firmware/radio) that things get more piecemeal and slightly confusing.
Sent from the future three weeks ago.

[Q][bootloader]starting from stock GB or ICS or JB? does it matter?

I'm comfortable with the process of going from stock to aftermarket firmware: root - CWM - backup - flash away
With three or four STOCK options available for the I777 (Gingerbread, Ice Cream Sandwich, Jellybean), Does it help to start from one stock firmware vs another? is there any advantage to flashing over the latest bootloaders, radios, ETC?
-Cyril
Edit: there are definitely differences in the Sbl.bin files, but there's no indication of what they affect.
extracted from i777UCKH7 Sbl.bin:
Secondary Bootloader v3.1 version.Copyright (C) 2011 System S/W Group. Samsung Electronics Co., Ltd.Board: %s %s / %s %s
C1REV 02Aug 27 2011 04:53:57
extracted from i777UCMD8 Sbl.bin:
Secondary Bootloader v3.1 version.Copyright (C) 2011 System S/W Group. Samsung Electronics Co., Ltd.Board: %s %s / %s %s
C1REV 03Sep 24 2012 13:09:44
Click to expand...
Click to collapse
4-2ndtwin said:
Concerning the .bin files in the KH7 and MD8 firmwares... I did a quick comparison of the boot, sbl, and modem .bin files with a MD5 hash generator. Thought that would be an easy way to see a verifiable result as to whether these files are different or not, even though they share the same file size with their counterpart. I included the modem.bin files as well because they share the same size also.
Interesting results...
KH7 MD5 #s
boot.bin = C41E06D0BC3F771ACEC30E85A24F8CDE
sbl.bin = CDDC18420052052890A3600C550FE874
modem.bin = 14BFC172DEC1A919D0CA3DA72A89D079
MD8 MD5 #s
boot.bin = 2F9260234A7442CD368A7BC755E18914
sbl.bin = E35A9BB350CAEF3460012712ECAFCB13
modem.bin = 92037CE8BC5FEB79E8644FC7FEBAAF96
Click to expand...
Click to collapse
creepyncrawly said:
Took a few minutes to play around with those files. Used the command line program vbindiff. It compares the hex, and highlights any bit that is different in the two files. Both the sbl.bin's and boot.bin's have more differences than similarities, at least as far as the hex contents go.
Also, in another thread, someone claims that with UCMD8 stock installed, a USB jig will not reset the flash counter. I think that behavior is controlled in the sbl.bin, so if true, that would indicate modification as well.
Click to expand...
Click to collapse
The only thing to take into consideration is that whatever custom kernel you flash to get CWM recovery should match the system version. Otherwise, which version you start with is irrelevant.
You should stay with the original secondary bootloader. As far as I know, none of the official distributions changed the bootloaders. Some of the leaks did have a different secondary bootloader that disabled the ability to reset the flash counter with a jig.
There is a thread in the development forum with all the modems from all the official and leak versions. In general, you have to experiment to find the best one for you, and that will mostly depend on your geographic location.
creepyncrawly said:
The only thing to take into consideration is that whatever custom kernel you flash to get CWM recovery should match the system version. Otherwise, which version you start with is irrelevant.
You should stay with the original secondary bootloader. As far as I know, none of the official distributions changed the bootloaders. Some of the leaks did have a different secondary bootloader that disabled the ability to reset the flash counter with a jig.
There is a thread in the development forum with all the modems from all the official and leak versions. In general, you have to experiment to find the best one for you, and that will mostly depend on your geographic location.
Click to expand...
Click to collapse
In all of the excitement about aocp6 (JB 4.3), I noticed that the first page now states: " ***Make sure you are on jellybean bootloaders before flashing this rom*** "
AOCP 4.6 (JB 4.1.2): " ***Make sure you are on gingerbread bootloaders before flashing this rom*** "
maybe the AOCP team throws that in the post to cover their bases, and doesn't matter for the I777?
With reference to compatibility with the newer firmwares available for the I777, I wonder whether the i777ucmd8 bootloaders would make any difference, IF they are actually different than the gingerbread or ICS bootloaders.
I've never seen any discussion about the changing bootloaders on this phone. But then I don't read much in the AOSP threads.
...so I asked the same question in the 4.3 AoCP6 thread, since they made mention of the bootloader versions...
crt60 said:
I would imagine there are differences between the bootloaders, apparently with android 4.3 it is even a better idea to have the latest bootloaders for your device. When android 4.1 came out, there were no jellybean bootloaders for the i777, and ics bootloaders weren't a big change from gingerbread. But android 4.3 is even pickier about how things are set up on the device. Bootloaders are usually backwards compatible, so jellybean bootloaders will work with gingerbread roms, but issues can happen if it is the other way around.
If you are going to flash 4.3 roms, it is a good idea to be on the latest bootloaders for your device...
Click to expand...
Click to collapse
fair enough.
^^^
Read the quote above...
It just shows that what someone says can sound really knowledgable, but in fact...
The original secondary bootloader extracted from UCKH7 full stock distribution: 1,310,720 bytes
and boot.bin: 131,072
The newest secondary bootloader extracted from UCMD8 full stock distribution: 1,310,720 bytes
and boot.bin: 131,072
creepyncrawly said:
^^^
Read the quote above...
It just shows that what someone says can sound really knowledgable, but in fact...
The original secondary bootloader extracted from UCKH7 full stock distribution: 1,310,720 bytes
and boot.bin: 131,072
The newest secondary bootloader extracted from UCMD8 full stock distribution: 1,310,720 bytes
and boot.bin: 131,072
Click to expand...
Click to collapse
I did notice that actually, but that wasn't an indication to me whether there were or were not any differences in the coding. When flashing ECU firmware to vehicles, for every different tune there was different coding, but the file size was always exactly the same. In fact, a file size other than 512kb or 1024kb for AM29f400/f800 eeprom, was our first indication of a corrupt or incomplete file.
perhaps that isn't the case here?
cyril279 said:
I did notice that actually, but that wasn't an indication to me whether there were or were not any differences in the coding. When flashing ECU firmware to vehicles, for every different tune there was different coding, but the file size was always exactly the same. In fact, a file size other than 512kb or 1024kb for AM29f400/f800 eeprom, was our first indication of a corrupt or incomplete file.
perhaps that isn't the case here?
Click to expand...
Click to collapse
I would imagine that a file containing vehicle tuning configuration data would only have small, incremental changes in values rather than any actual additional lines of code. I think the case is different with a bootloader.
dsmboost said:
I would imagine that a file containing vehicle tuning configuration data would only have small, incremental changes in values rather than any actual additional lines of code. I think the case is different with a bootloader.
Click to expand...
Click to collapse
You're right, the ecu firmware changes were indeed changes in data, vs. additional lines; perhaps the bootloader scenario is much different.
Either way, we're still dealing with a lot of i think, perhaps, and probably. @creepyncrawly is right, such answers aren't the most helpful here.
When building, for instance, a windows application, when you recompile the file, the size will always change. Even a small change, such as changing a few text words, and nothing else, will cause a change of at least a few bytes. I'm not sure what tool is used to compile the boot loaders, but I can assure you that if they made any modifications to the files, they would have different sizes.
I put them into winmerge to compare the binaries:
The sbl.bin and boot.bin packaged with the ucmd8 4.1.2 firmware are both notably different than sbl.bin and boot.bin packaged with the uckh7 2.3.6 firmware, despite the fact that the files are exactly the same size for each release.
Withut knowing what those specific differences are or mean, there's still no telling whether there's any advantage to starting with stock gb, ics, or jb binaries.
I'm curious and interested to find out more. However, I don't have any extra time to play with things this week. When I do get some free time, I'll be on it for sure.
We all make assumptions, sometimes based on past experience, and sometimes not. The phenomenon is particularly noticeable in these forums, lol.
creepyncrawly said:
^^^
Read the quote above...
It just shows that what someone says can sound really knowledgable, but in fact...
The original secondary bootloader extracted from UCKH7 full stock distribution: 1,310,720 bytes
and boot.bin: 131,072
The newest secondary bootloader extracted from UCMD8 full stock distribution: 1,310,720 bytes
and boot.bin: 131,072
Click to expand...
Click to collapse
Well for one, I never took the bootloaders and compared them by hex, or compared them at all, and second I'm am speaking in general, not necessarily specific of this rom, regardless if you want to compare the bootloaders and find there is no difference, cool.
But it still stands, knowledgeable sounding or not, it is always a good idea to use the latest bootloaders for your device.
crt60 said:
Well for one, I never took the bootloaders and compared them by hex, or compared them at all, and second I'm am speaking in general, not necessarily specific of this rom, regardless if you want to compare the bootloaders and find there is no difference, cool.
But it still stands, knowledgeable sounding or not, it is always a good idea to use the latest bootloaders for your device.
Click to expand...
Click to collapse
Sounds reasonable. By the way, I hope you didn't take that personally. I'm as likely to say something like that about myself as about what someone else says. cyril279 suggests that the boot loaders from different distributions have different contents even though they have exactly the same file size. It would be interesting to follow up on that.
Concerning the .bin files in the KH7 and MD8 firmwares... I did a quick comparison of the boot, sbl, and modem .bin files with a MD5 hash generator. Thought that would be an easy way to see a verifiable result as to whether these files are different or not, even though they share the same file size with their counterpart. I included the modem.bin files as well because they share the same size also.
Interesting results...
KH7 MD5 #s
boot.bin = C41E06D0BC3F771ACEC30E85A24F8CDE
sbl.bin = CDDC18420052052890A3600C550FE874
modem.bin = 14BFC172DEC1A919D0CA3DA72A89D079
MD8 MD5 #s
boot.bin = 2F9260234A7442CD368A7BC755E18914
sbl.bin = E35A9BB350CAEF3460012712ECAFCB13
modem.bin = 92037CE8BC5FEB79E8644FC7FEBAAF96
4-2ndtwin said:
Concerning the .bin files in the KH7 and MD8 firmwares... I did a quick comparison of the boot, sbl, and modem .bin files with a MD5 hash generator. Thought that would be an easy way to see a verifiable result as to whether these files are different or not, even though they share the same file size with their counterpart. I included the modem.bin files as well because they share the same size also.
Interesting results...
KH7 MD5 #s
boot.bin = C41E06D0BC3F771ACEC30E85A24F8CDE
sbl.bin = CDDC18420052052890A3600C550FE874
modem.bin = 14BFC172DEC1A919D0CA3DA72A89D079
MD8 MD5 #s
boot.bin = 2F9260234A7442CD368A7BC755E18914
sbl.bin = E35A9BB350CAEF3460012712ECAFCB13
modem.bin = 92037CE8BC5FEB79E8644FC7FEBAAF96
Click to expand...
Click to collapse
Though different I would assume allot of the changes with the bootloader are just compilation/release dates. In hex, they are similar enough to figure their code is the same. I guess its main function is to initialize the device and start the kernel, so whatever changes with that, who knows.
They are different in hex and different in md5, even though their size is the same, unless Samsung can target a compilation size, they've been changed somehow.
[Q]starting from stock GB or ICS or JB? Bootloaders ARE different.
cyril279 said:
I put them into winmerge to compare the binaries:
The sbl.bin and boot.bin packaged with the ucmd8 4.1.2 firmware are both notably different than sbl.bin and boot.bin packaged with the uckh7 2.3.6 firmware, despite the fact that the files are exactly the same size for each release.
Withut knowing what those specific differences are or mean, there's still no telling whether there's any advantage to starting with stock gb, ics, or jb binaries.
Click to expand...
Click to collapse
4-2ndtwin said:
Concerning the .bin files in the KH7 and MD8 firmwares... I did a quick comparison of the boot, sbl, and modem .bin files with a MD5 hash generator. Thought that would be an easy way to see a verifiable result as to whether these files are different or not, even though they share the same file size with their counterpart. I included the modem.bin files as well because they share the same size also.
Interesting results...
KH7 MD5 #s
boot.bin = C41E06D0BC3F771ACEC30E85A24F8CDE
sbl.bin = CDDC18420052052890A3600C550FE874
modem.bin = 14BFC172DEC1A919D0CA3DA72A89D079
MD8 MD5 #s
boot.bin = 2F9260234A7442CD368A7BC755E18914
sbl.bin = E35A9BB350CAEF3460012712ECAFCB13
modem.bin = 92037CE8BC5FEB79E8644FC7FEBAAF96
Click to expand...
Click to collapse
I didn't think to compare the md5 (like a checksum, correct?)
So we agree that there are differences in between uckh7 and ucmd8.
I didn't see sbl.bin in ucll6, suggesting that the firmware was fine to run on the uckh7 sbl.bin.
The fact that sbl.bin was re-introduced to the ucmd8 release, but was NOT included in the ucll6 release suggests more changes than release date or info, which lends to the AoCP team's advice to use JB bootloaders (for their 4.3 rom).
Although it's only partially relevant, I still wish we had stronger sense of the changes and how they may or may not affect the various firmware installs. I admit that figuring it further is well beyond my level, and I don't have sufficient interest to do the work to figure it out. My ECU forum would have told me to stop conjecturing, reverse engineer the code, and report back with conclusive results.
@creepyncrawly
@crt60
@4-2ndtwin
thanks for the time and the input.
Took a few minutes to play around with those files. Used the command line program vbindiff. It compares the hex, and highlights any bit that is different in the two files. Both the sbl.bin's and boot.bin's have more differences than similarities, at least as far as the hex contents go.
Also, in another thread, someone claims that with UCMD8 stock installed, a USB jig will not reset the flash counter. I think that behavior is controlled in the sbl.bin, so if true, that would indicate modification as well.

[Q] Flashing modems

I'm on SaberMod 5.0.2 and have the VRUEMJ9 modem. I've had the VRAMC modem as well and my LTE coverage has generally been appalling. I'd like to try the ND7 modem (or even one of the older VRALLJB or VRALL4 modems)--I'm under no illusion that it will magically fix anything, but again my current service is so bad that I'll try anything.
I found the nd7_radio.zip file easily enough, and the older modem files are at: http://forum.xda-developers.com/showthread.php?t=2577809. My problem is that I can't get any of them to install through TWRP, as I keep getting the "error executing updater binary in zip" error.
I thought these files were flashable through TWRP (I do have the latest 2.8.6.0 version). I've read some posts that it's easier to use Odin, but I've also seen plenty of posts that say TWRP should work.
I'd rather not use Odin--if that means I'm stuck with my current modem then I can live with that. But if there is a way to install another I'd like to try. Any ideas?
Thanks in advance.
geoclooney said:
I'm on SaberMod 5.0.2 and have the VRUEMJ9 modem. I've had the VRAMC modem as well and my LTE coverage has generally been appalling. I'd like to try the ND7 modem (or even one of the older VRALLJB or VRALL4 modems)--I'm under no illusion that it will magically fix anything, but again my current service is so bad that I'll try anything.
I found the nd7_radio.zip file easily enough, and the older modem files are at: http://forum.xda-developers.com/showthread.php?t=2577809. My problem is that I can't get any of them to install through TWRP, as I keep getting the "error executing updater binary in zip" error.
I thought these files were flashable through TWRP (I do have the latest 2.8.6.0 version). I've read some posts that it's easier to use Odin, but I've also seen plenty of posts that say TWRP should work.
I'd rather not use Odin--if that means I'm stuck with my current modem then I can live with that. But if there is a way to install another I'd like to try. Any ideas?
Thanks in advance.
Click to expand...
Click to collapse
I installed nd7 through twrp that's weird. The modem won't make your signal better. With that said the mj9 has always been a fan favorite. I'd just stick with that.

Categories

Resources