Related
Yes i know the fastboot trick, but can anyone guide me towards making the nandroid backup files into a update.zip that would work?
I'd like to know too ^^.
Me too.
I've successfully scripted the automated creation of a file structure into which the contents of BOOT.IMG, SYSTEM.IMG, DATA.IMG, CACHE.IMG and SD-EXT.IMG are extracted. The script also creates a valid update-script file under ./META-DATA/....
The only issue I have is that I'm using windows so the .IMG files extracted as a yaffs file system, looses the original file permissions. I need someway to recreate the permissions in the update.zip.
Thats all.
Having a way of converting a nandroid backup to an update.zip means you can very easily cook custom roms from a nandroid backup, and port ROMs across phones using a portable .ZIP format.
Maybe dsixda can help
http://forum.xda-developers.com/showthread.php?t=633246
"OR [cook a rom] from a Nandroid backup (under /sdcard/nandroid) [NOT RECOMMENDED]:
Copy the system.img and boot.img files from the backup folder to your kitchen's original_update folder
NOTE: The Nandroid-backup method of cooking is not the best way to cook, because the kitchen may not account for various advanced options that were cooked outside of this kitchen (these options are in the update-script file which was in the original ROM but is not in the backup. The kitchen needs to re-create this file and 'guess' those options). However, it will support Nandroid backups that already have basic features like root, busybox and /data/app functionality. "
You get nandroid backup images by backing up a ROM which was flashed from an update.zip package. What is then the point of recreating that update.zip package?
giant is right with the klitchen by dsixda you can make an update.zip form nandroid very easy
Guys, we're missing the point.
To clarify:
The "point of recreating the ZIP ROM file" are numerous. For example, to create a ROM where the original ROM isnt available, i.e. to create a portable ROM based on an existing set of images in a phone where the phone and/or its sdcard cannot be removed or where we do not wish to remove the card. Simple. But more importantly, the process is a learning and development activity that I want to undertake, its a personal decision, for which support would be welcome.
Secondly, dsixda issues many caveats around cooking ROMs from nadroid backups. It simply doesnt work - I've tried it - thus his caveat is correct and should be observed. Furthermore, his kitchen creates windows based ZIP files. The process is inherently flawed for creating ROMs for linux because the ZIP files contain a windows file structure which does not contain the appropriate linux based file permissions (linux being the O/S base system on android. The restore operation does not work - in stock form - because one looses the critical file permissions, UID and GID that are required in order for the ROM to function correctly, and in some instances from my experience, to even boot up! His update-script attempts to reinstate the appropriate permissions, UID and GIDs, however, and as dsixda admits, the process is not foolproof and does not cover all eventualities, combinations and scenarios. Thus, the issue of permissions, GID and UID remains outstanding.
For these reasons, in my humble view, the issue of permissions is critical in ensuring a successful ROM flash from [linux based] .IMG files. Once this is resolved, the rest of the process is trivial. Indeed, if this one issue could be resolved, then dsixda's kitchen would mature from a useful toolset, to a truly wonderous one-stop solution.
well i don't know what people have tried and got to work or not, but it can eb done and have been done before, one of my sliderom build was done froma nandroid
soo i guess it's up to how much effort you put into it and use the kitchen as a tool, but not only use it, cause then you fail, if you don't do some manual work, nothing 100% automated will ever be a big succes
I have a solution.
I am coding this up as we speak.
My solution will extract the file permission, UID and GID from the .IMG , for each contained file. My script then runs as part of the update-script (i.e. RUN_PROGRAM restore-protection) subsequent to a ROM flash. Thus, the resultant file structure after a ROM update is exactly the same as that contained within the .IMG files.
EDIT:
coding complete.
will test tomorrow on existing phone + sdcard.
The purpose of this exercise is to 'clone' an existing phone software load, as ROM file, that can then be flashed. My script takes all partition images (system, data, cache, sd-ext and so on), creates a ROM that includes functionality that will - when flashing - restore the exact permissions, GID and UID as written in the backup files (.IMG), thus cloning the phone.
I plan to update the script in future so that APK files can be added or removed, and additional low level features such as kernel pre-empting, scheduling and other features can be added --- I think they call this "a kitchen" in Android speak.??
From your description of what you're doing it sounds like you could end up with the simplest and closest to a one click kitchen that allows users with less knowledge to fully backup / restore / clone their phone (rom, personal settings, data and all). A lot of noobs might like this tool big time
Any progess made on this? I have been trying to create a rom for a nandroid backup. When I go to flash it, I get symlink errors and the flash fails.
dazxda said:
I have a solution.
I am coding this up as we speak.
My solution will extract the file permission, UID and GID from the .IMG , for each contained file. My script then runs as part of the update-script (i.e. RUN_PROGRAM restore-protection) subsequent to a ROM flash. Thus, the resultant file structure after a ROM update is exactly the same as that contained within the .IMG files.
EDIT:
coding complete.
will test tomorrow on existing phone + sdcard.
The purpose of this exercise is to 'clone' an existing phone software load, as ROM file, that can then be flashed. My script takes all partition images (system, data, cache, sd-ext and so on), creates a ROM that includes functionality that will - when flashing - restore the exact permissions, GID and UID as written in the backup files (.IMG), thus cloning the phone.
I plan to update the script in future so that APK files can be added or removed, and additional low level features such as kernel pre-empting, scheduling and other features can be added --- I think they call this "a kitchen" in Android speak.??
Click to expand...
Click to collapse
Do you have a link?
dazxda said:
I have a solution.
I am coding this up as we speak.
My solution will extract the file permission, UID and GID from the .IMG , for each contained file. My script then runs as part of the update-script (i.e. RUN_PROGRAM restore-protection) subsequent to a ROM flash. Thus, the resultant file structure after a ROM update is exactly the same as that contained within the .IMG files.
EDIT:
coding complete.
will test tomorrow on existing phone + sdcard.
The purpose of this exercise is to 'clone' an existing phone software load, as ROM file, that can then be flashed. My script takes all partition images (system, data, cache, sd-ext and so on), creates a ROM that includes functionality that will - when flashing - restore the exact permissions, GID and UID as written in the backup files (.IMG), thus cloning the phone.
I plan to update the script in future so that APK files can be added or removed, and additional low level features such as kernel pre-empting, scheduling and other features can be added --- I think they call this "a kitchen" in Android speak.??
Click to expand...
Click to collapse
Hi, could yo share your script? I'm also working on something similar, and could use a bit of help
OMG this is exactly what I need.. I read all the way to the end and then ARRGGGGGG.. no more responses in months. Have you made this script yet? If no .. does anyone else have instructions on taking a nandroid backup and creating an IMG or ?
My personal reasons.. I have a Craig CMP741E tablet that is stuck in the android logo screen after attempting the factory update.. the one that crashes EVERY1's tablet. And there is no working way that I have found to fix it. No custom roms or factory roms that can be flashed without FIRST having the tablet ON and turn on USB Debugging or already have CWM installed. So I cannot use ADB or any other method I can find to do this.
I have a buddy with the same tablet that is rooted and has GAPPS and everything on it. He gave me a copy of his nandroid backup but now I cannot find anything I can actually do with it. If I can turn it into an Update.zip or IMG I can simply put on SD Card.. restart and cross my fingers.
lilc420 said:
OMG this is exactly what I need.. I read all the way to the end and then ARRGGGGGG.. no more responses in months. Have you made this script yet? If no .. does anyone else have instructions on taking a nandroid backup and creating an IMG or ?
My personal reasons.. I have a Craig CMP741E tablet that is stuck in the android logo screen after attempting the factory update.. the one that crashes EVERY1's tablet. And there is no working way that I have found to fix it. No custom roms or factory roms that can be flashed without FIRST having the tablet ON and turn on USB Debugging or already have CWM installed. So I cannot use ADB or any other method I can find to do this.
I have a buddy with the same tablet that is rooted and has GAPPS and everything on it. He gave me a copy of his nandroid backup but now I cannot find anything I can actually do with it. If I can turn it into an Update.zip or IMG I can simply put on SD Card.. restart and cross my fingers.
Click to expand...
Click to collapse
Can you access the tablet's fastboot mode? Turn the tablet fully off, then hold the Menu button and the Power button. I don't have your tablet, but it's a standard boot mode.
Make sure you have the tablet connected to the PC. You should see it pop up in the Device Manager, or by doing "fastboot devices" from a command prompt.
If you can get there, you may be able to flash a recovery image.
Hi, does anybody knows if there is a response for this post??, i am looking for a method to convert the images files that are included in a rom stock (for using with sp flash tool) to an update.zip file. I have no way to use sp flash tool because my tablet has a hardware problem with microusb port and the only way is flashing a new rom via microSD card with an update.zip..
Maybe the solution is in another thread, please be kind and give me a link or at least give me some suggestions where to look for.
Hi Guys today I'm going to show u how to add OTA updates for your rom.
So what is it basically???
Everyone knows it lol
So lets start with the business.
1)First of all get the latest apk from here
https://www.otaupdatecenter.pro/
2)Put this app in your rom's /system/app
3)Pick a ROM ID that you will use in our database(No spaces)
4)Add the following properties to your build.prop:
otaupdater.otaid=<ROM ID you picked from previous step>
otaupdater.otatime=<Date/time of this build in yyyymmdd-hhmm format>
otaupdater.otaver=< version number/name>
5)Package your ROM, generate an MD5 of the zip file, and upload it on any file sharing site
6)Then make your account and add your rom (update) on the site (OTA)
7)You will need the ROM ID you picked, the device you packaged for, and the URL and MD5 of the zip file.
8)For any further updates, just make sure you update the "otatime" and "otaver" properties in build.prop
Hope this HELPS!
Wanna hit THANKS!!,
Then there's A button for that
How do you generate a md5 of the rom?
Nice guide, i understand everything excepting that step.
Isn't this taken from here: http://forum.xda-developers.com/showthread.php?t=1803562
Thanks
Helped me a lot for building my own rom trying to learn rn and it was very helpful of you
Hi all,
The usual DISCLAIMER: I am in no way responsible for any and all damage the following does to your phone.
I'm new to this whole flashing ROM business, having started by flashing stock Lollipop upgrade to my LG G3 as I was using it on Ultra Mobile and therefore wasn't getting OTA updates. I've now done the same with my brand new Moto Maxx (US) xt1250, which has the exact same phone as the xt1254 (as I'm sure all of you know but it bears repeating just in case).
I found the easiest way to install all of the upgrades to Lollipop from stock Kitkat was just to download these files:
http://rootjunkysdl.com/files/?dir=Droid Turbo/Firmware
I then extracted them into ADB + Fastboot folder one at a time, going in this order:
VRZ_XT1254_KDF21.128-15_15_CFC.xml.zip
VRZ_XT1254_SU2-12_12_CFC.xml.zip
VRZ_XT1254_SU3TL-38_38_CFC.xml.zip
VRZ_XT1254_SU4TL-44_44_CFC.xml.zip
After copying the first group of files into the ADB/fastboot folder and starting up my phone in bootloader, I'd simply click on the batch file for that group (for example the VRZ_XT1254_KDF21.128-15_15_CFC.bat file) to install the first Rom. Then I'd unzip the files for the second lot xml files, allow it to replace the files that had the same name, and then click on the batch file for that Rom.
However, all this was a bit tedious, and I imagine that some people might like to be able to just go direct to the latest 5.1 OTA of stock verizon without all this copying and pasting. So I renamed the files for the first xml batch with a "1" in front, the second with a "2" and so on, and renamed all the commands in the batch xml files to include these modifications. I then put all of the batch file commands together, but also removed some of the unnecessary commands (like "pause", "%fastboot% oem fb_mode_set" and "%fastboot% oem fb_mode_clear") to give you one single batch file.
IN SUMMARY:
I have at your disposal all of the images with modified names, and a single batch command that'll install the upgrades sequentially, which you can do by simply copying all of these files into adb/fastboot folder and clicking on "VRZallupgrades".
I tested this on my droid, and it works great!
My question is this: Would anyone find this helpful? I'm currently uploading all 8GB of files to mega.nz on ****ty hotel internet, but it should be done by tomorrow morning.
Rhuagh3 said:
Hi all,
The usual DISCLAIMER: I am in no way responsible for any and all damage the following does to your phone.
I'm new to this whole flashing ROM business, having started by flashing stock Lollipop upgrade to my LG G3 as I was using it on Ultra Mobile and therefore wasn't getting OTA updates. I've now done the same with my brand new Moto Maxx (US) xt1250, which has the exact same phone as the xt1254 (as I'm sure all of you know but it bears repeating just in case).
I found the easiest way to install all of the upgrades to Lollipop from stock Kitkat was just to download these files:
http://rootjunkysdl.com/files/?dir=Droid Turbo/Firmware
I then extracted them into ADB + Fastboot folder one at a time, going in this order:
VRZ_XT1254_KDF21.128-15_15_CFC.xml.zip
VRZ_XT1254_SU2-12_12_CFC.xml.zip
VRZ_XT1254_SU3TL-38_38_CFC.xml.zip
VRZ_XT1254_SU4TL-44_44_CFC.xml.zip
After copying the first group of files into the ADB/fastboot folder and starting up my phone in bootloader, I'd simply click on the batch file for that group (for example the VRZ_XT1254_KDF21.128-15_15_CFC.bat file) to install the first Rom. Then I'd unzip the files for the second lot xml files, allow it to replace the files that had the same name, and then click on the batch file for that Rom.
However, all this was a bit tedious, and I imagine that some people might like to be able to just go direct to the latest 5.1 OTA of stock verizon without all this copying and pasting. So I renamed the files for the first xml batch with a "1" in front, the second with a "2" and so on, and renamed all the commands in the batch xml files to include these modifications. I then put all of the batch file commands together, but also removed some of the unnecessary commands (like "pause", "%fastboot% oem fb_mode_set" and "%fastboot% oem fb_mode_clear") to give you one single batch file.
IN SUMMARY:
I have at your disposal all of the images with modified names, and a single batch command that'll install the upgrades sequentially, which you can do by simply copying all of these files into adb/fastboot folder and clicking on "VRZallupgrades".
I tested this on my droid, and it works great!
My question is this: Would anyone find this helpful? I'm currently uploading all 8GB of files to mega.nz on ****ty hotel internet, but it should be done by tomorrow morning.
Click to expand...
Click to collapse
It is not necessary to flash anything other than VRZ_XT1254_SU4TL-44_44_CFC.xml.zip. This file contains the full firmware package and does not need previous updates to build upon.
TheSt33v said:
It is not necessary to flash anything other than VRZ_XT1254_SU4TL-44_44_CFC.xml.zip. This file contains the full firmware package and does not need previous updates to build upon.
Click to expand...
Click to collapse
seriously? Wow. major noob moment. With my Lg G3 it definitely wasn't possible to flash straight to 5.1
Thanks for the heads up
Hello,
Dear XDA Member, and Yota-User
I wanted by this post, share has a .zip file (38GB) divided into 9 parts of 4GB
This large file contains all the original roms for Yotaphone 2 (with the flash tools yota-flasher with that driver) known to date.
The file contains the following roms: See below (for my part I only used HK and RU and quickly tested EU in Android version 5.0) but it contains other original rom. (I would not do a tutorial on flash or other, they are available on XDA by doing some research)
(I do not know what the APC, CN, ME roms) I did not use the other tool inside the .zip file.
I only used the modified version of yotaflasher which is a user-modified version of I do not know the name.
This yota-flasher edit sends the system file into several sparse files. (It works.) For my case I did not flasher "radio" (the better and the deleted folder (radio) of the firmware file) then placed the folder yota-flasher at the root of C: and extract the rom ( That you want) into a "firmware" folder.
Deleted the "radio" folder
It is a torrent clone that I found I do not know where.
I put on my One Drive (Microsoft because I have space)
I hope this will allow others who like me search for its rare and hard to find files.
If this (file grouping or the torrent from which I downloaded it belongs to you or it is you who did it.) Tell me, I will add your name or pseudo at the bottom of this page.
(As I know more where, or from what source I found this, I can not name the name to whom it belongs.)
To the moderator please, I do not know if my status allows me to publish this thread, or if I can publish the external link on my onedrive. So please contact me to tell me what to do if I have a rule. I would not have allowed myself if we found the files on the site xda or other. All the threads I read to download its files were either dead internally or returned to a yotaphone ftp that is no longer valid. Be indulgent also because English is not my main language, I used a translator. Thank you very much. If my thread is not accepted because of the OneDrive link or my status, can you tell me or communicate my nickname to a person who could do so? Thank you.
On my one drive, find a txt file with all the MD5 checksum of each file and also a txt file that shows all the files in the zip archive.
LINK FOR DOWNLOAD:Yotaphone2 Onedrive link
So here are the roms contained in the file (all are original (unmodified)
APC :
4.4.3-S01-003-APC.0.3.56c.zip
4.4.3-S01-003-APC.0.3.61a.zip
5.0.0-APC.1.44.zip
5.0.0-APC.1.65.zip
CN :
4.4.3-S01-003-CN1.0.3.01a.zip
4.4.3-S01-003-CN1.0.3.17a.zip
4.4.3-S01-003-CN1.0.3.20a.zip
4.4.3-S01-003-CN1.0.3.25a.zip
4.4.3-S01-003-CN1.0.3.28a.zip
4.4.3-S01-003-CN1.0.3.30a.zip
4.4.3-S01-003-CN1.0.3.32a.zip
EU :
4.4.3-S01-003-EU1.0.3.51a.zip
4.4.3-S01-003-EU1.0.3.56a.zip
4.4.3-S01-003-EU1.0.3.61a.zip
5.0.0-EU1.1.124b.zip
5.0.0-EU1.1.39.zip
5.0.0-EU1.1.44.zip
5.0.0-EU1.1.60.zip
5.0.0-EU1.1.87a.zip
HK :
4.4.3-S01-003-HK1.0.3.56a.zip
4.4.3-S01-003-HK1.0.3.61a.zip
5.0.0-HK1.1.44.zip
5.0.0-HK1.1.66.zip
ME :
4.4.3-S01-003-ME1.0.3.52a.zip
4.4.3-S01-003-ME1.0.3.56a.zip
4.4.3-S01-003-ME1.0.3.61a.zip
5.0.0-ME1.1.45.zip
5.0.0-ME1.1.60.zip
RU :
4.4.3-S01-003-RU1.0.3.52a.zip
4.4.3-S01-003-RU1.0.3.56a.zip
4.4.3-S01-003-RU1.0.3.61a.zip
5.0.0-RU1.1.112.zip
5.0.0-RU1.1.124.zip
5.0.0-RU1.1.59.zip
5.0.0-RU1.1.87.zip
5.0.0-RU1.1.99.zip
5.0.0-S01-003-RU1.0.1.30.zip
5.0.0-S01-003-RU1.0.1.44.zip
6.0.1-RU1.1.28.zip
6.0.1-RU1.1.30.zip
System.img (do not know what this means, it is inside torrent)
Will soon be on XDA
Mickynuts
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.