Related
Hi All,
I've used ODIN many times but always using "monkey-click-this" instructions. I'd like to learn why I'm clicking this or that and which files should be in which box(es) because it's not always clear.
I know the PDA button is to flash the boot image and/or file system; the PHONE button flashes the radio driver. But it's not always clear what's in a given tar file. Does a given XYZ.TAR contain just the boot files or also include the radio? If it does, do I put it's name in both boxes? What if I put a PHONE file in the PDA box or vice versa?. As I understand it, the tar files know what's in them and where the file should go in the file system. So what does the PHONE button/box do that's different from PDA?. And then there's the inscrutable PIT (Partition Information Table) file. Usually it's not needed but sometimes it is. How do I know when?. I'm a seasoned software professional, but this has me very confused. Any enlightenment would be greatly appreciated by me (and lots of other monkeys too I bet).
If you want to learn, I would recommend looking into Heimdall instead. From what I've read Odin is leaked samsung software while Heimdall is opensource and multiplatform, and Heimdall will thus have better documentation availible.
PIT Magic is the All In One solution for Creating, Editing and Analyzing Samsung PIT Files.
What are Samsung PIT Files?
PIT files contain the Partition Information Table (PIT) for Samsung Android phones. Different firmware versions may require different partition layouts so the necessary PIT file 'tells' Odin how to set up the phone partitions correctly for the specified firmware to be installed.
The PIT file contains all the relevant information for each required partition such as Partition Name, Flash File Name, Block Size, Block Count etc. and also contains some unknown properties that maybe identifiers or flags of some sort.
Big thanks to Benjamin Dobell and Adam Outler for their extensive knowledge. I have read alot of threads where I found all of your comments regarding pit files very useful.
Click to expand...
Click to collapse
PIT Magic's Main Features:
Create New PIT Files from scratch.
Edit Existing PIT Files and change all available properties.
Analyze a PIT File and create a human readable report of all Partition entries.
Export PIT Analysis to Text File or Copy to Clipboard direct from the User Interface.
Add or Remove Partition entries to a New or Existing PIT File.
Save options to write changes to Existing PIT File or write a New PIT File altogether.
Download Link: PIT_Magic_v1.3.10_Release.zip (Dev-Host)
Click to expand...
Click to collapse
Please Note: PIT Magic requires Microsoft .NET Framework 4.0 to be installed on your PC.
Compatible with Windows XP, Vista, 7
Click to expand...
Click to collapse
Whats NEW in PIT Magic v1.3.10
1. Removed Unknown PIT File Properties #1 to #8 and replaced with 5 Dummy Data Blocks consisting of 4 bytes each as per the Samsung PIT File Specification.
2. Changed the 'Unknown PIT File Properties' Group to PIT File Header Information.
3. Added Option to Display Dummy Data in String or Hexadecimal Format.
4. Fixed a bug with the Reset Form Button. Now it will undo changes made to the PIT File Header Dummy Data fields as well as the currently selected PIT Entry.
5. Changed the layout of the User Interface and made a few slight cosmetic adjustments.
6. Changed the layout of the PIT File Analysis Report to reflect the changes to the PIT Header Information.
7. Fixed a few bugs regarding loading and saving of PIT Files in the User Interface.
8. Removed some redundant and duplicated code and tidied it up in a few places.
9. Fixed PIT File Modified prompt when Creating New / Open Existing / Exit Application. Changes made are now detected properly including to PIT Header Information.
Whats NEW in PIT Magic v1.1.4
1. Changed File Name to Flash File Name and Added FOTA File Name.
2. Changed Chip Identifier to Binary Type.
3. Changed Partition Identifier to Device Type.
4. Changed Partition Flags to Identifier.
5. Changed Unused to Attribute.
6. Changed Unknown #1 in PIT Entry to Update Attribute.
7. Changed Unknown #2 to File Offset and Unknown #3 to File Size. (Obsolete PIT Parameters).
8. Added Thousand separator text formatting to Block Size and Block Count in the User Interface and Analysis UI.
9. Updated User Interface and fixed a few file modified detection bugs that failed to prompt user to save changes on Exit / Open / New.
10. Fixed a Null Reference bug when cancelling 'Save As...' Dialog.
Whats NEW in PIT Magic v1.0.8
Initial Release.
1st
havnt plashed a single pit file in a year+ of owning the gs2
well u can never be too sure
thanks
this looks awesome
Subscribed...
Sent from my SPH-D710 using xda premium
PIT Magic v1.1.4 has now been released!
Enjoy!
lyriquidperfection said:
PIT Magic v1.1.4 has now been released!
Enjoy!
Click to expand...
Click to collapse
This is awesome...I'm waiting for Samsung to send my cell back..wanted me to pay $170 since i cracked the screen on the way to ship it . Hopefully this can help me out. Maybe there should be a collection of stock PIT files?
Will this work with any Samsung Device? Like my S3?
elesbb said:
Will this work with any Samsung Device? Like my S3?
Click to expand...
Click to collapse
Yes PIT Magic will edit ANY PIT File you throw at it!
Sent from my HTC Desire S using Tapatalk 2
lyriquidperfection said:
Yes PIT Magic will edit ANY PIT File you throw at it!
Sent from my HTC Desire S using Tapatalk 2
Click to expand...
Click to collapse
Now i just need to obtain the stock PIT file so i can edit it and make my system partition smaller
Do you have any idea where/how i can get one? I highly doubt i'll be able to make one from scratch...
elesbb said:
Now i just need to obtain the stock PIT file so i can edit it and make my system partition smaller
Do you have any idea where/how i can get one? I highly doubt i'll be able to make one from scratch...
Click to expand...
Click to collapse
Search on XDA or Google for I9300 PIT.
Be careful though as there are different ones for 16GB and 32GB depending which model variant you have.
Sent from my HTC Desire S using Tapatalk 2
lyriquidperfection said:
Search on XDA or Google for I9300 PIT.
Be careful though as there are different ones for 16GB and 32GB depending which model variant you have.
Sent from my HTC Desire S using Tapatalk 2
Click to expand...
Click to collapse
Ha shockingly i was able to find it. However i have the SGH-T999 Tmo d2Tmo variant. Found a whole bunch of PIT's and even a way to get your stock PIT here but now i need to figure out what everything means exactly in my PIT file. I apologize if im annoying you xD
Here is what i feel needs to be edited.
Code:
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 14
Attribute: 5 (READ / WRITE)
Update Attribute: 5 (FOTA)
Block Size: 221,184
Block Count: 3,072,000
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SYSTEM
Flash FileName: system.img.ext4
elesbb said:
Ha shockingly i was able to find it. However i have the SGH-T999 Tmo d2Tmo variant. Found a whole bunch of PIT's and even a way to get your stock PIT here but now i need to figure out what everything means exactly in my PIT file. I apologize if im annoying you xD
Here is what i feel needs to be edited.
Code:
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 14
Attribute: 5 (READ / WRITE)
Update Attribute: 5 (FOTA)
Block Size: 221,184
Block Count: 3,072,000
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SYSTEM
Flash FileName: system.img.ext4
Click to expand...
Click to collapse
If you are just looking to resize the system partition, then just change the Block Size.
Sent from my HTC Desire S using Tapatalk 2
lyriquidperfection said:
If you are just looking to resize the system partition, then just change the Block Size.
Sent from my HTC Desire S using Tapatalk 2
Click to expand...
Click to collapse
Ahh so i resize the block size not the number of blocks? I was thinking it was the number of blocks.. but if i take my max memory in MB and divide that my the block size number, theoretically that should let me know how many megabytes are in each block. Right?
So i edited block size by 102460 from 221184 and nothing happened. Says it flashed successfully but nothing changed in my partitions table.. did i do something wrong?
elesbb said:
Ahh so i resize the block size not the number of blocks? I was thinking it was the number of blocks.. but if i take my max memory in MB and divide that my the block size number, theoretically that should let me know how many megabytes are in each block. Right?
So i edited block size by 102460 from 221184 and nothing happened. Says it flashed successfully but nothing changed in my partitions table.. did i do something wrong?
Click to expand...
Click to collapse
Adjust block count aswell but I think both have to match up somehow. I could be wrong but do some research first.
Sent from my HTC Desire S using Tapatalk 2
anyone have a PIT for the TMo S2 - T989?
lyriquidperfection said:
Adjust block count aswell but I think both have to match up somehow. I could be wrong but do some research first.
Sent from my HTC Desire S using Tapatalk 2
Click to expand...
Click to collapse
I've done so much Googling and got no where -.- I'll keep trying and change my keywords and what not. Thanks for all your help!
Sent from my SGH-T989 using Tapatalk 2
---------- Post added at 07:01 PM ---------- Previous post was at 07:01 PM ----------
MR2-MiKe said:
anyone have a PIT for the TMo S2 - T989?
Click to expand...
Click to collapse
Use this link. They have instructions for creating a pit file.
http://rootzwiki.com/topic/32867-pits-for-tmo-sgs3/
Sent from my SGH-T989 using Tapatalk 2
MR2-MiKe said:
anyone have a PIT for the TMo S2 - T989?
Click to expand...
Click to collapse
Here is the PIT File for SGH-T989 / SGH-T989D:
http://d-h.st/juD
Sent from my HTC Desire S using Tapatalk 2
lyriquidperfection said:
Here is the PIT File for SGH-T989 / SGH-T989D:
http://d-h.st/juD
Sent from my HTC Desire S using Tapatalk 2
Click to expand...
Click to collapse
thanks dude...ill try it out when my phone gets here monday.
Great googly moogly. Goodsir, I'm drooling. Time to adjust and tweak partitions like Old HTC devices. Now where's my old Captivate?
lyriquidperfection said:
Adjust block count aswell but I think both have to match up somehow. I could be wrong but do some research first.
Sent from my HTC Desire S using Tapatalk 2
Click to expand...
Click to collapse
No, you only need to change the block count, not the block size.
Also, if you take blocks away from /system/, remember to add them to another partition, or you'll just be wasting blocks by not assigning them to any partition at all.
Hi guys, googling around i found this link where we can download .pit files for our tablet...As far as i know, these files are related with the partition sizes...Has anyone already tried this way with odin to reduce system partition?Thanks for the reply!
http://www.droidevelopers.com/f363/...-files.html?11722-Download-OPS-amp-PIT-files=
Pit file for i9505XXUHOJ2
I have a hand-me-down 16gb LTE GT-i9505 from my son in London. (I'm in Australia). After a system crash during an OTA update I was unable to flash with Kies or Odin; tried different computers and OS's so then tried with heimdall using a downloaded pit file (I stupidly didn't save the original pit file beforeflashing) and the stock rom (i9505XXUHOJ2) from Sammobile. I don't know whether the pit file was suitable for my 16gb S4 or not, but heimdall still wouldn't flash the unzipped rom until I created a heimdall package with it. Even then, heimdall reported a failure to flash after successfully flashing eg one partition, so I just kept stopping and reconnecting to heimdall (Linux Mint 64 bit) until all partitions one at a time until all seemed to flash. Very messy process! (On my part not really understanding what I was doing)
Now my phone is crashing and rebooting constantly after working ok for a couple of weeks. This was the same issue that led me to update in the first place. I replaced with new battery. No change. Reinstalled stock again today without error using heimdall,but I'm still getting the random crashes. So I thought trying to reinstall again with a correct pit file this time might help. I'm thinking hardware problems after that as it also crashes in recovery and reboots.
Can someone direct me to a correct pit file ? - I have no idea which ones are compatible with my device and the stock rom I'm trying to get working again. This is my primary phone.
My hardware details are:
Device type: jflte
Name: jfltexx
Qcom/MSM8960 (32BIT)
msm8960/apq8064
GPU adreno 320
Modem: mdm9215m
Hardware revision MP 0.900
Bootloader i9505XXUHOJ2
PDA i9505XXUHOJ2
Baseband: i9505XXUHOJ2
CSC: BTU
Hi,
You could utilize search function around Galaxy S4 forum to get the proper pit for your phone.
Sent from my GT-I9500
krasCGQ said:
Hi,
You could utilize search function around Galaxy S4 forum to get the proper pit for your phone.
Click to expand...
Click to collapse
I have been searching all day through xda and found nothing that seems to help. Googled for days without result either. There are pit files out there. But none seem to match my device/stock rom combination. And I've read (newbie on these matters) that it does matter which pit file is used, and could be the cause of my constant crashing problems if partitioning is not quite right.
If you could narrow my search options I'd be happy to keep searching but not for lack of trying on my part so far.
gc2712 said:
I have been searching all day through xda and found nothing that seems to help. Googled for days without result either. There are pit files out there. But none seem to match my device/stock rom combination.
Click to expand...
Click to collapse
I think there are no specialized type for your phone (unlike my GT-I9500). Any pit files for regular GT-I9505 should be okay.
If you still 100% unsure, download BTU stock firmware via SamFirm with "Nature..." checked. It has pit file bundled with it and has 4 files when extracted (Pit is inside CSC's tar.md5).
Sent from my GT-I9500
krasCGQ said:
I think there are no specialized type for your phone (unlike my GT-I9500). Any pit files for regular GT-I9505 should be okay.
If you still 100% unsure, download BTU stock firmware via SamFirm with "Nature..." checked. It has pit file bundled with it and has 4 files when extracted (Pit is inside CSC's tar.md5).
Click to expand...
Click to collapse
Thanks for the follow up. Much appreciated. I hadn't heard of Samfirm before but have downloaded it and will get the stock ROM today using it. I was under the impression that the pit file did matter depending on the capacity of the phone. (16gb,32gb,64gb). Unfortunately, my son can't remember which he purchased - he bought it online unlocked and the original invoice gives no indication, and I'm not sure whether PhoneInfo just looks at partition sizes or whether it actually interrogates the hardware to assess internal flash memory size (It says I have 16Gb).
If the pit file version really doesn't matter then I'll just use the one in the downloaded stock ROM, but I was hoping to verify this first.
Edit: It seems there is no CSC tar.md5 in the extracted download. Only the flashable partitions etc. I have attached an image of 7zip extraction. Any other thoughts/ideas?
google this; all-pit-files-for-samsung-softbrick_28
you´ll see a site with all sam pit files; you could also check for a software named magic pit, here in the forum, it allows you to check and alter the pit files easily.
Ghangrel said:
google this; all-pit-files-for-samsung-softbrick_28
you´ll see a site with all sam pit files; you could also check for a software named magic pit, here in the forum, it allows you to check and alter the pit files easily.
Click to expand...
Click to collapse
Many thanks for the search tip. I'll have a look at magic pit too, but with a little more observant attention I also noticed the CSC*.tar.md5 file and it did indeed contain a single file called JFLTE_EUR_OPEN.pit. So I am beginning to assume there is only one pit file for different i9505 international (and unlocked) variants? I have found several pit files now and had a look at them with pit magic (EMS Professional now) and they all seem the same as the one I installed on my phone and the one I downloaded with SamFirm.
What I would like to be able to calculate is the size of the partitions, but not sure how block size and block number fit together to calculate that number. Any advice?
gc2712 said:
Thanks for the follow up. Much appreciated. I hadn't heard of Samfirm before but have downloaded it and will get the stock ROM today using it. I was under the impression that the pit file did matter depending on the capacity of the phone. (16gb,32gb,64gb). Unfortunately, my son can't remember which he purchased - he bought it online unlocked and the original invoice gives no indication, and I'm not sure whether PhoneInfo just looks at partition sizes or whether it actually interrogates the hardware to assess internal flash memory size (It says I have 16Gb).
If the pit file version really doesn't matter then I'll just use the one in the downloaded stock ROM, but I was hoping to verify this first.
Edit: It seems there is no CSC tar.md5 in the extracted download. Only the flashable partitions etc. I have attached an image of 7zip extraction. Any other thoughts/ideas?
Click to expand...
Click to collapse
gc2712 said:
Many thanks for the search tip. I'll have a look at magic pit too, but with a little more observant attention I also noticed the CSC*.tar.md5 file and it did indeed contain a single file called JFLTE_EUR_OPEN.pit. So I am beginning to assume there is only one pit file for different i9505 international (and unlocked) variants? I have found several pit files now and had a look at them with pit magic (EMS Professional now) and they all seem the same as the one I installed on my phone and the one I downloaded with SamFirm.
What I would like to be able to calculate is the size of the partitions, but not sure how block size and block number fit together to calculate that number. Any advice?
Click to expand...
Click to collapse
Yes, that's it. Flash all files (AP, BL, CP, and CSC) on the corresponding section in ODIN. You don't need to provide additional pit because your phone will be partitioned using pit file inside CSC tar.md5 (re-partition should be checked). It'll do the magic.
Sent from my GT-I9500
krasCGQ said:
Yes, that's it. Flash all files (AP, BL, CP, and CSC) on the corresponding section in ODIN. You don't need to provide additional pit because your phone will be partitioned using pit file inside CSC tar.md5 (re-partition should be checked). It'll do the magic.
Click to expand...
Click to collapse
I'm caught up with things for a few days now, but will give it a go. Many thanks.
gc2712 said:
What I would like to be able to calculate is the size of the partitions, but not sure how block size and block number fit together to calculate that number. Any advice?
Click to expand...
Click to collapse
you can use the pitmagic to do this, it shows the starting block [block count] and the block size of each partition... one of the pits I´ve got was wrong, I could check it at sva partition table.
about what you want to know, I do believe the userdata is left alone only marking the starting block but the size is just identified by the program and not limited by the pit for start.
I'm still trying to figure out if my phone is 16gb or 32gb storage. If I use phoneinfo-Samsung it reports 16gb. If I input the device imei into imei.info.com I get 32gb listed for my device. All the other info for my s4 on that site is correct. Which source is likely to be correct? I am a little bit suspicious that phoneinfo-samsung might only look at formatted partitions to calculate storage rather than reporting on the hardware flash memory chip. I am wondering whether my constant system crashes may be because of incorrectly formatted partitions. Any advice?
gc2712 said:
I'm still trying to figure out if my phone is 16gb or 32gb storage. If I use phoneinfo-Samsung it reports 16gb. If I input the device imei into imei.info.com I get 32gb listed for my device. All the other info for my s4 on that site is correct. Which source is likely to be correct? I am a little bit suspicious that phoneinfo-samsung might only look at formatted partitions to calculate storage rather than reporting on the hardware flash memory chip. I am wondering whether my constant system crashes may be because of incorrectly formatted partitions. Any advice?
Click to expand...
Click to collapse
use twrp recovery to wipe>advanced wipe : then u can check the size of the data / internal storage ; don´t forget to check if it´s checked in mount option
Ghangrel said:
use twrp recovery to wipe>advanced wipe : then u can check the size of the data / internal storage ; don´t forget to check if it´s checked in mount option
Click to expand...
Click to collapse
Haven't had the courage to install TWRP yet. ?
gc2712 said:
Haven't had the courage to install TWRP yet.
Click to expand...
Click to collapse
it´s a simple task. to be sure, extract the recovery file from your stock rom or from sammobile´s, then you can flash it again.
While trying to modify my KW88 Pro watch to run AsteroidOS I took the advice of the program and clicked "Format All + Download" without fully understanding what it does. It deletes all partitions. The install then failed with some random errors but I had a brick. I managed to recover it with KW88 Pro firmware (KW88Pro_V1.5_NHH_B_20190114) I found on discourse.fullandroidwatch.com (don't know how legit it is but at least it works now).
While this guide is how to fix the "PMT changed for the ROM, it must be downloaded" error, the above is relevant. You must find firmware for your watch that has the default partition layout if you did not take a backup before formatting or if you don't know the partition layout. In a nutshell you get the PMT error when the partition layout of the scatter file does not match the partition layout of the device, and the stock firmware + scatter file is needed as a reference point. My error:
https://imgur.com/aFZKfOo
Let's compare the start addresses of those 3 partitions to the stock firmware:
https://imgur.com/rV3XBt2
Boot and Logo partitions are the same, but User Data starts at a different address.
If we compare the contents of both the scatter files we see the same thing:
https://imgur.com/OYw10d3
https://imgur.com/DNQ1Ztw
In a nutshell what you need to do is clone the partition layout (start address variables + offset variable) into the new scatter file, but maintain all other variables of the scatter file. It should also be mentioned that there are other partitions in the scatter file that I had from AsteroidOS that did not match the physical layout of the firmware I used, and even though I was not flashing them I still had to edit the scatter file.
Afterwards using these settings I flashed successfully:
https://imgur.com/TdVRDEV
I also want to note that the End Addresses will not match even with the correct partition layout because different firmware has different sizes on disk, despite the space allocated for the partitions. In theory if you want you could reclaim unused space by tweaking the original scatter file and then the custom scatter file, but it may also impact your future updates if the partition is too small.
Hope I made someone's day easier, best of luck
Can you explain the getting the partition start and offset address part?
Because I think im going to brick my phone really soon if I can't make this auto-generated scatter I got from internet work to flash my phone back to stock rom.
The scatter itself already has some bugs with userdata partition (Too large)
kutiz21 said:
Can you explain the getting the partition start and offset address part?
Because I think im going to brick my phone really soon if I can't make this auto-generated scatter I got from internet work to flash my phone back to stock rom.
The scatter itself already has some bugs with userdata partition (Too large)
Click to expand...
Click to collapse
Sure thing. The scatter file which is for stock firmware vs. the file for new firmware will not allocate the space on disk based on what partitions are actually, physically on it. The new scatter file for custom firmware will be for what the devs had on their device, but not what you actually have on yours (different hardware versions, android releases, w.e.). What you need to do is take the existing partitions of your device, the start addresses for them, add the size of that partition to get the end address and using that information supply that data to the new scatter file. You COULD in theory also change the partition sizes but that is more prone to error so I did not recommend that. So what I did would visually look like this, the | are partition start / end markers
Original scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxx|
vs new scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxx|
vs the patched scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxx....................||xxxxxxxxxxxxxxxxxxxxxxx....................................................||xxxxxxxxxx........|
Tl;Dr An offset is basically a way of saying address + data/space (until next segment at next address).
Intersting
printf() said:
Sure thing. The scatter file which is for stock firmware vs. the file for new firmware will not allocate the space on disk based on what partitions are actually, physically on it. The new scatter file for custom firmware will be for what the devs had on their device, but not what you actually have on yours (different hardware versions, android releases, w.e.). What you need to do is take the existing partitions of your device, the start addresses for them, add the size of that partition to get the end address and using that information supply that data to the new scatter file. You COULD in theory also change the partition sizes but that is more prone to error so I did not recommend that. So what I did would visually look like this, the | are partition start / end markers
Original scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxx|
vs new scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxx|
vs the patched scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxx....................||xxxxxxxxxxxxxxxxxxxxxxx....................................................||xxxxxxxxxx........|
Tl;Dr An offset is basically a way of saying address + data/space (until next segment at next address).
Click to expand...
Click to collapse
I used Smartphone flash tool version 3 and 5 and I have managed to use my own image to flash numerous phones, encrypted with a key or with no keys (Auth file).
Usually, I would use Google's method of flashing back rom that is using a zip file contains bunch of flashable system images and let fastboot app itself flash it.
I dumped my images using dd tool and img2simg (Full blown raw ext4 file, not sparsed.)
Because fastboot likes sparse images rather than raw ones and flashable sparse images can be easily flashed with SP tool normally (It can make phones bootable but will more likely making phone unbootable most of the time)
I do aware that I need to adjust the address thing. But normally, using the start address based on the scatter. SP app can automatically calculates how large the image and it can prevents you from flashing because it is too large.
But this particular phone won't flash even if it is the stock rom. Which dumped and got its scatter file generated by some sketchy "miracle box".
My best guess is that the scatter file was tied to specific emmc chip and it is not for my phone's emmc so there might be some difference there.
Because when I use the REAL flash scatter file from actual OEM (In this case, Nokia 1, European Variant). It can make my APAC counterpart can be flashed normally, even with my custom sparsed or raw image (These 2 variants were kinda different, technically.)
I would like to point out that newer SP flash tool app tends to hate to co-operate with scatter scripts so that could be a reason (I used older build of version 5 and it only gets the userdata bug, but it does lags the app when the bug "PMT changed for the ROM, it must be downloaded" show up. Because it was a bug and it hadn't fixed in that build, which is fixed in the latest build of SP app when I attempt to flash)
And flashing extracted "stock" rom from flash tool and flash it back over fastboot tool tends to break system OTA and make my phone on bootloop (I highly doubted it was the raw image thing, because of the free space it can allocated. I flashed it raw back then I think because i don't know what happened yet, keep in mind that stock rom images shipped for SP flash tool were most likely in raw state, not compressed like sparse images)
And SP flash tool also hates raw dd images too (too big?????)
So like. What do I need to fix the script? What program that can calculate the exact offset for it? I still be able to flash the stock rom with fastboot fine. But for "unforeseen consequences" that makes it unbootable, I still need it.
Say the scatter is not reliable or doesn't exist. How do I use the readback function and then use some aged apps like MTK droid tool to generate actual offsets and possibly generates scatter for me (Most likely will not work because my phone's Android is too new for it). I used to work with Android 4.2.2 so it's really easy back then.
kutiz21 said:
So like. What do I need to fix the script? What program that can calculate the exact offset for it? I still be able to flash the stock rom with fastboot fine. But for "unforeseen consequences" that makes it unbootable, I still need it.
Say the scatter is not reliable or doesn't exist. How do I use the readback function and then use some aged apps like MTK droid tool to generate actual offsets and possibly generates scatter for me (Most likely will not work because my phone's Android is too new for it). I used to work with Android 4.2.2 so it's really easy back then.
Click to expand...
Click to collapse
I'm not sure how to get the data when no original scatter file exists, I was fortunate enough to find a reference for my stock OS. The other scatter file was for AsteroidOS. I think the easiest way to explain what I did would be to share the scatter files. Effectively start address + partition size should not be larger than the start address of the next partition.
Stock scatter file:
https://pastebin.com/tfFDCPfT
Original AsteroidOS scatter file:
https://pastebin.com/0z7DtL9u
Patched AsteroidOS scatter file:
https://pastebin.com/iiYZTzBt
Take note that in my original post screenshots, AstreroidOS was only flashing 3 partitions (corresponding to the is_download: true/false field of the scatter file). That told me that those were the partitions / boundaries that need to match, the other partitions were irrelevant (for the purpose of flashing anyway). AsteroidOS itself is contained inside the userdata partition, effectively leaving other ~20 partitions as "lower layers" or unused.
printf() said:
I'm not sure how to get the data when no original scatter file exists, I was fortunate enough to find a reference for my stock OS. The other scatter file was for AsteroidOS. I think the easiest way to explain what I did would be to share the scatter files. Effectively start address + partition size should not be larger than the start address of the next partition.
Stock scatter file:
https://pastebin.com/tfFDCPfT
Original AsteroidOS scatter file:
https://pastebin.com/0z7DtL9u
Patched AsteroidOS scatter file:
https://pastebin.com/iiYZTzBt
Take note that in my original post screenshots, AstreroidOS was only flashing 3 partitions (corresponding to the is_download: true/false field of the scatter file). That told me that those were the partitions / boundaries that need to match, the other partitions were irrelevant (for the purpose of flashing anyway). AsteroidOS itself is contained inside the userdata partition, effectively leaving other ~20 partitions as "lower layers" or unused.
Click to expand...
Click to collapse
So my insights were true. It does automatically calculates the free space of a partition to whether allow you to flash or not. But I tried fiddling with it and it doesn't work. I might try to individually comment out those partitions as unflashable and try it out.
One more thing is that I used to had this error. But it will be gone when I explicitly referencing SP flash tool the preloader partition image (flashing it or not doesn't matter) alongside with all of my custom images but they must be fully loaded in the app.
You will not be able to flash if it can't fully loaded all partitions that has the property "is_download: true". Maybe that should allow me to do the flash.
Any more thoughts on " boundary_check and is_reserved"? Because I used to poke with these and managed to flash my other phone successfully.
I don't have the phone to test right now but more food for thought I guess.
Cheers!
kutiz21 said:
Any more thoughts on " boundary_check and is_reserved"? Because I used to poke with these and managed to flash my other phone successfully.
I don't have the phone to test right now but more food for thought I guess.
Cheers!
Click to expand...
Click to collapse
Not sure what is_reserved does, but boundary_check probably validates the scatter file vs. the layout on the disk. If you don't do the check though you are risking overwriting a partition which might be needed for the lower layer functionality - keystore, firmware, etc.