Quote:
Originally Posted by kam187
How did you dump the rom? are you using dd or something on a partition?
Be VERY carefull about trying to odin any image back to the phone. Its EXTREMELY dangerous. (except the proper odin files of course).
Can you host you're update file?
|
I've added the link to the update file to the bottom of the OP. It's zipped down to the 12MB on account of the extra 28MB being zeroed. I left it this way just to be safe.
Some brave soul who hasn't updated yet can try placing this file in the proper directory and letting us know what happens, for example, if they reboot or go to Settings | Software Update. I have tried it on mine but I was already updated at the time - no prompts for an update.
Oh Snap! I keep messing up the path! Its fixed now!
Recommended code below, extract from zip and copy the fota_delta_dp file to the sdcard. Requires rooted phone.
Code:
su
cat /sdcard/fota_delta_dp > /data/data/com.wssyncmldm/fota_delta_dp
exit
As for the ROM dump, I used dd to read out the /dev/block/bml# block devices. These correspond to the phone's flash partitions on a physical level, with /dev/block/bml0!c being the entire flash device.
Friendly Advise: DO NOT TRY TO WRITE TO BLOCK DEVICES!
Anyway, the images dumped from the bml devices correspond to the partitions and files referenced in ODIN. I've compared the dumps per byte and they are the same. Partitions that contain file systems rather than raw data are headed with metadata (possibly a bitmap of file usage). The actual file system begins on offset 0xA80000 on these partitions.
The exception to this are bml1 and bml2. For both of these, the data from the 'arm9boot' file is split between them. These are different partitions on the device and have different functions during bootstrapping.
An arm9boot file consists of bml1 joined with bml2 at offset 0x200000 (the end of bml1).
Partitions 3, 10, and 11 are blank on my device.
Partition 7 seems to have some kind of file system on it, but has no corresponding ODIN image. Contents are unknown.
Partition 13 is 99% blank aside from a few stray bits at the very beginning.
Summery of block devices and partitions follows. Partition names originate from the 'partition' ODIN file (in the BOOTLOADER archive).
Partitions with file systems should be accessed via STL devices with no offset - edited table.
Code:
Device Partition Image Offset Size (KiB)
bml1 MIBIM arm9boot 2048
bml2 OEMSBL1 arm9boot @0x200000 512
bml3 OEMSBL2 {blank} 512
bml4 APPSBL arm11boot 1024
bml5 AMSS amss 23040
bml6 RECOVER recovery 6144
bml7 EFS2 {radioFS} 0xA80000 23040
bml8 APPS kernel 6144
stl9 EFS2APPS system 0xA80000 226304
bml10 FOTA {blank} 8192
bml11 RFBACKUP {blank} 512
stl12 CACHE cache 0xA80000 40960
bml13 PARAM {unknown} 1024
stl14 USERDATA userdata 173568
What this means is we can make custom ODIN images! If not by editing the partitions manually (or building them using tools) then by modifying them on the device and dumping it.
Update: Simply hexediting the flash file system header out so that the remaining image matches the contents of the original ODIN images does not seem to work.
The problem is that dumping the BML devices with files systems on them (vs RAW) produces an image that is too large. In the originals, all the files were allocated near the beginning of the ROM, and the rest was zeroed (in NAND flash this means 0xFF). After the update I noticed that files were allocated at the end as well. This means one cannot simply remove the extra zeroed space to make it fit for ODIN.
The STL devices work at a higher level, translating addresses in flash so they can work with normal file systems. Using an STL image instead of the edited BML image may work.
The downside of using STL devices for file system dumps is that they are only enabled on specific partitions. The good thing is these other partitions do not really concern us unless we want to edit the radio code (lets leave this alone).
Unfortunately the error in trying to flash the BML image forced me to ODIN back to the UVIJ6 firmware. Once I receive the update again I will test the new ROM dump and release a no-root-needed ROM update via ODIN if it works.