Related
This is about the coolest thing you can imagine.
DEATHSPL is OBSOLETE.
We can repartition these things -- to ANY layout we like -- withOUT changing or modifying the SPL!
This is even compatible with a STOCK SPL! I.e. 0.95.0000.
This is something I discovered while looking at the MTD drivers.
The mtd drivers accept partition table specified on the KERNEL COMMAND LINE! And this SUPERSEDES the automatic table discovery method.
This is the command line argument for STOCK partition layout:
Code:
mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)
You can boot a kernel with a modified partition table using one of two methods;
the "-c" parameter to fastboot allows you to add kernel parameters. This is good for booting RECOVERY images and applying custom layouts.
The second method is to build the custom layout into your boot.img or recovery.img.
This can be done using the "--cmdline" parameter to mkbootimg.
Notes: The smallest possible partition is 128k.
The partition sizes must be MULTIPLES of 128k and must start on an offset that is a multiple of 128k. The memory size is 256MB precisely.
Note: DO NOT modify ANYTHING before the START of the boot partition, i.e. offset 0x2bc0000. If you do, it won't boot!
***** EDIT:
We now have a BETA implementation of this concept: http://forum.xda-developers.com/showpost.php?p=6916491&postcount=39
Thanks go to Firerat, who did the actual implementation work in converting CM 5.0.8 to this process.
Also thanks to skraw at CM forums who asked a silly question that started the gears a crankin and ended up getting this as an answer.
** just goes to show that there is no such thing as a stupid question.
Sweet stuff!
Now we can finally reduce the size of that useless cache partition. And ROM devs can actually fit anything they want without a headache.
This should be leaps and bounds more useful on the phones with more ROMs space like the 32A Magic, where the cache is absurdly large.
xaueious said:
Sweet stuff!
Now we can finally reduce the size of that useless cache partition. And ROM devs can actually fit anything they want without a headache.
This should be leaps and bounds more useful on the phones with more ROMs space like the 32A Magic, where the cache is absurdly large.
Click to expand...
Click to collapse
I'll ask a silly question, and full intent not to derail the thread.. why have partitions at all? (do they accomplish some level of protection that simple unix privs do not if /system, /data, /cache, etc were all on the same partition?) Hopefully not a super stupid question (I understand their use on my home linux box, but fail to see what value they add here)
I already pointed this out months ago.. but no one ever tried to make a use out of it.
sweeeeeet! good ****, someone make sure cyanogen knows about this.
mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?
mattv888 said:
mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?
Click to expand...
Click to collapse
Yeah Im curious about that too
mattv888 said:
mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?
Click to expand...
Click to collapse
Yes, in theory.. I'm not sure how usable it would be, but purely theoretically you should be able to drop cache and userdata to 128k, mount them both on the sdcard instead and flash a 200mb+ system image.
With a bit of modification to the way we flash images at the moment, there's no reason devs can't include a custom partition layout to fit the requirements of every release.
This is an awesome find by both lbcoder and maxisma, who seem to have discovered it independently.. I totally missed maxisma's annoucement though
Whoever found it first, this rules.
This would be really awesome to see can't wait
Macrophage001 said:
This would be really awesome to see can't wait
Click to expand...
Click to collapse
Wait for what?
This is something that everyone can do for themselves!
All you need is a calculator (to calculate memory offsets and sizes), the first post of this thread, and this:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
unpack your boot.img, mkbootimg it back with the specified kernel command line, shove it into your update.zip (or fastboot it into the phone), and you're done-ish.
Take the most recent CM for example:
1) extract boot.img, unpack it, repack it with the kernel command line specified (modified to your specifications), put it back in the update.zip, resign, and put it on your sdcard.
2) Phone in fastboot mode, fastboot -c "same kernel command line as boot.img is packed with" boot recovery.img, flash your update.zip, done.
And then every time the phone boots up, it'll have the customized partition table since it is built into the boot.img.
with this custom partition layouts, do we also need to do something to the recovery to make nandroid/bart recognize the new layout?
haozheng91 said:
with this custom partition layouts, do we also need to do something to the recovery to make nandroid/bart recognize the new layout?
Click to expand...
Click to collapse
Same steps as the rom, just ensure you *never* flash *any* spl or radio for any reason from a re-partitioned recovery with a cache partition that does not match the spl's actual cache start location. Or you will be in the market for a jtag adapter to fix your brick.
Making this user friendly will need some configuration work.
ezterry said:
Same steps as the rom, just ensure you *never* flash *any* spl or radio for any reason from a re-partitioned recovery with a cache partition that does not match the spl's actual cache start location. Or you will be in the market for a jtag adapter to fix your brick.
Making this user friendly will need some configuration work.
Click to expand...
Click to collapse
There's security built in to that process....
the cache partition has to get a special header applied in order for the update to be taken, and if the spl or radio partition was mapped differently, this header will be badly broken. I believe that there are also checksums on the spl and radio images that should be checked by the SPL prior to actually installing them. Part of the reason for this is to ensure that the image was actually written correctly to the cache partition.
Another good find.
maxisma said:
I already pointed this out months ago.. but no one ever tried to make a use out of it.
Click to expand...
Click to collapse
Don't see why. Hopefully people will be able to understand how to do this, get rid of the deathspl along with all the spam topics that come from the resulting bricks.
lbcoder said:
There's security built in to that process....
the cache partition has to get a special header applied in order for the update to be taken, and if the spl or radio partition was mapped differently, this header will be badly broken. I believe that there are also checksums on the spl and radio images that should be checked by the SPL prior to actually installing them. Part of the reason for this is to ensure that the image was actually written correctly to the cache partition.
Click to expand...
Click to collapse
I can test it but I've seen invalid radio images trap a phone in flash radio.. I highly recommend just not tempting fate with this one and just installing 1.33.2003 or 1.33.2005 before starting custom partitions.. then you can deal with radio/alt recovery flashes from there.
Leave the recovery for android system install/uppdate/backup operations.
any success?
ezterry said:
I can test it but I've seen invalid radio images trap a phone in flash radio.. I highly recommend just not tempting fate with this one and just installing 1.33.2003 or 1.33.2005 before starting custom partitions.. then you can deal with radio/alt recovery flashes from there.
Leave the recovery for android system install/uppdate/backup operations.
Click to expand...
Click to collapse
Possibly with an invalid radio, but DEFINITELY NOT with an offset-cache partition. It simply can't possibly do anything without the right header.
And I don't see any benefit at all for installing a 1.x SPL. The ability to flash radio or SPL direct depends on fastboot, and if you have fastboot, you can break the update-x cycle simply by wiping the misc partition.
And for that matter, the 0.95.0000 SPL withOUT fastboot still could flash an nbh file in any circumstance where any of the engineering/pseudoengineering SPLs could enter fastboot.
Tempting fate is to flash a radio or spl to begin with. If you want to feel really safe, you can always build a recovery that lacks the ability to flash the radio or spl. This would, of course, force you to go back to the SPL's partition table (i.e. another recovery) to flash either of those.
Or how about this: query the kernel command line -- if the partition table is set on the kernel command line, don't allow flashing of radio or spl.
lbcoder said:
This is the command line argument for STOCK partition layout:
Code:
mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)
Notes: The smallest possible partition is 128k.
The partition sizes must be MULTIPLES of 128k and must start on an offset that is a multiple of 128k. The memory size is 256MB precisely.
Note: DO NOT modify ANYTHING before the START of the boot partition, i.e. offset 0x2bc0000. If you do, it won't boot!
Click to expand...
Click to collapse
I'm working my way thru the math.. I set up an OpenOffice spreadsheet (alas its fairly inept at working with hex #'s, so I have to do all the match in decimal and convert it to hex (couldn't find a way to make it add in hex, and it can't seem to convert big hex numbers back to dec.. even tho it can convert that same dec # into hex... grr...) anyway... this is the table I came up with (using D and H to denote Decimal and Hex versions of the same #s)
Code:
Block k M bytes(D) bytes(H) StartD EndD StartH EndH
misc 256 0.25 262144 40000 38535168 38797312 24C0000 2500000
recover 5120 5 5242880 500000 40632320 45875200 26C0000 2BC0000
boot 2560 2.5 2621440 280000 45875200 48496640 2BC0000 2E40000
system 69120 67.5 70778880 4380000 48496640 119275520 2E40000 71C0000
cache 69120 67.5 70778880 4380000 119275520 190054400 71C0000 B540000
userdat 76544 74.75 78381056 4AC0000 190054400 268435456 B540000 10000000
size 229900288 219.25
The only "gap" I saw was after misc.. ie. there was space between the end of misc and the beginning of recovery (1792k by my calculations).. is that correct, or did I fudge my math up? Any idea what is in that gap?
Also by taking the final addr and subtracting the start addr, it looks like 219.25M (out of the 256M you mention) are being used? (actually that does not take the "gap" memory into account). Any idea what is using the other 256-219.25=36.75M?
Note: not trying to poke any holes here.. I'm trying to get a good understanding of this, so I can give it a try.
EDIT: added M column to table
Yes.. there are some internal partitions after misc.
If you have 1.33.2005 or 1.33.2003 spls ask it the partition layout yourself: fastboot oem listpartition
zim2dive said:
I'm working my way thru the math.. I set up an OpenOffice spreadsheet (alas its fairly inept at working with hex #'s, so I have to do all the match in decimal and convert it to hex (couldn't find a way to make it add in hex, and it can't seem to convert big hex numbers back to dec.. even tho it can convert that same dec # into hex... grr...) anyway... this is the table I came up with (using D and H to denote Decimal and Hex versions of the same #s)
Code:
Block k M bytes(D) bytes(H) StartD EndD StartH EndH
misc 256 0.25 262144 40000 38535168 38797312 24C0000 2500000
recover 5120 5 5242880 500000 40632320 45875200 26C0000 2BC0000
boot 2560 2.5 2621440 280000 45875200 48496640 2BC0000 2E40000
system 69120 67.5 70778880 4380000 48496640 119275520 2E40000 71C0000
cache 69120 67.5 70778880 4380000 119275520 190054400 71C0000 B540000
userdat 76544 74.75 78381056 4AC0000 190054400 268435456 B540000 10000000
size 229900288 219.25
The only "gap" I saw was after misc.. ie. there was space between the end of misc and the beginning of recovery (1792k by my calculations).. is that correct, or did I fudge my math up? Any idea what is in that gap?
Also by taking the final addr and subtracting the start addr, it looks like 219.25M (out of the 256M you mention) are being used? (actually that does not take the "gap" memory into account). Any idea what is using the other 256-219.25=36.75M?
Note: not trying to poke any holes here.. I'm trying to get a good understanding of this, so I can give it a try.
EDIT: added M column to table
Click to expand...
Click to collapse
You don't need to do any subtraction. The start address is itself the size of the "gap" before it. I.e. look at startD column: 38535168 -- that would be ~38.5 MB or (divide by 1024x1024) 36.75 MiB, the same as the number you got through your subtraction.
That gap is for the radio and SPL, and some proprietary data, like IMEI, radio lock, security, etc.
Of course, you could just ASK someone who has a deathSPL for the numbers....
Not about the gap between misc and recovery: I believe that the splash images go there.
In any case, you don't need to worry about any of those....
The only partitions you need to map are the ones that *are* mapped.
misc, recovery, and boot should be left alone. As should the STARTING address of system.
You should start by adjusting the SIZE of system,
Adjust the OFFSET of cache by the SAME AMOUNT as you adjusted the SIZE of system.
Adjust the SIZE of cache by whatever you feel is appropriate,
Adjust the OFFSET of userdata to (OFFSET+SIZE) of cache.
And according to the mtd documentation, you should be able to set the SIZE of userdata to "-" in order for it to fill all of the remaining space. Either that, or hardcode it to 0x10000000-OFFSET.
Hello folks,
it's me again (RaymanFX aka Chris Hesse) and I want to introduce you to a little, but important project.
My goal is to finally be able to backup the 'boot' partition of our device in CWM and TWRP or others !
How can we get to that ?
Well, I already have an exact plan on how to do it.
1. Step : examining the boot partition (LNX) size and offsets
2. Step : invoke a kernel hack to parse the partition layers to the system at runtime (WARNING : This will only work on a hack-enabled kernel) - I will provide one.
3. Step : re-enable 'boot' partition backup (in TWRP, e.g.) I will recompile TWRP with newest code when the time is right
Ok, so what do we have ?
1. To examine these partition layout sizes and offsets, we have to strip of the hex value of !ANDROID or ANDROID! of /dev/block/mmcblk0 using the dd command.
I already did this.
Here's how to do it :
Code:
iMac21:~ RaymanFX$ adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
~ # dd if=/dev/block/mmcblk0 of=/sdcard/20m.bin bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 1.271406 seconds, 15.7MB/s
~ # exit
iMac21:~ RaymanFX$ adb pull /sdcard/20m.bin /Users/RaymanFX/Desktop
2413 KB/s (20971520 bytes in 8.487s)
Then open a hex editor and search for the sring value 'ANDROID!' and copy that value.
Mine is :
Code:
0x37FFED
Now we have to convert this to get the sizes and offsets we need (I work together with Dees_Troy to resolve this).
-> To be fixed soon !
2. When we proceed, we need to invoke a kernel hack at compile time, so every old kernel needs to be recompiled.
-> I will provide a recompiled and hack-enabled harmony kernel soon
Code:
Here will be the required code fix; commit at my GitHub
3. And last but not least :
A new version of TWRP needs to be compiled to re-include the boot partition for the nandroid system, i will compile one with the newest updates once the previous steps are made.
As always, I need assistance to proceed faster with your help.
I can do everything on my own, but it will take time. What I need the most urgent is someone to convert the hex values to get the offset and size values.
One for me
The recompiled harmony kernel and information for kernel devs will be posted here.
Last one, open disscussion now !
NOTE : THIS IS A [DEV] THREAD, SO PLEASE DON'T CLUTTER IT WITH QUESTIONS THAT DON'T BELONG IN HERE. IF YOU WANT TO SUPPORT ME, HIT THE 'THANKS' BUTTON TO KEEP ME MOTIVATED !
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
hanthesolo said:
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
Click to expand...
Click to collapse
so we can back up kernel, each time we restore a rom from CWM it does not restore kernel so we have to reflash that.
hanthesolo said:
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
Click to expand...
Click to collapse
The 'boot' partition (LNX, in our case) stores the whole kernel and the ramdisk, combined as a boot image.
This means if I am successful, we can just backup the kernel in recovery along with the rom, like other android devices already do.
E.g. when you flash a new rom, but backed up the old one first, you have to flash a kernel compatible with the rom manually when going back to your backup as of now.
After my work has succeeded, you can just restore the old android, which restores the kernel automatically.
RaymanFX said:
The 'boot' partition (LNX, in our case) stores the whole kernel and the ramdisk, combined as a boot image.
This means if I am successful, we can just backup the kernel in recovery along with the rom, like other android devices already do.
E.g. when you flash a new rom, but backed up the old one first, you have to flash a kernel compatible with the rom manually when going back to your backup as of now.
After my work has succeeded, you can just restore the old android, which restores the kernel automatically.
Click to expand...
Click to collapse
Okay, I thought so, I just needed confirmation. Bad question #3: why can't we did the kernel partition, and restore it that way?
hanthesolo said:
Okay, I thought so, I just needed confirmation. Bad question #3: why can't we did the kernel partition, and restore it that way?
Click to expand...
Click to collapse
Ask this to ASUS !
Those guys gave us a crappy partition layout, meaning we only have /staging for flashing boot and recovery blobs, NO REAL PARTITIONS holding those files. -> UNITL NOW ! I examined the boot offset and size ...
Seems like the recovery ad boot partition share the same offsets and sizes .. will check this
EDIT : Progress : I have the offsets and sizes right at my hands !
See : My hex offset is 0x37ffed, I take this and convert it to decimal ()10 ... then I get 3669997, which fits our definitions perfectly (7chars).
Now, we have to divide this by the block layer size (512), we get 7167.962890625, which is ugly.
The second one has hex offset at 0x87ffe8, decimal at 8912872, decided by 512 makes 17407.953125
Very nice work, seems like more and more people are learning to dev.
RaymanFX said:
Ask this to ASUS !
Those guys gave us a crappy partition layout, meaning we only have /staging for flashing boot and recovery blobs, NO REAL PARTITIONS holding those files. -> UNITL NOW ! I examined the boot offset and size ...
Seems like the recovery ad boot partition share the same offsets and sizes .. will check this
EDIT : Progress : I have the offsets and sizes right at my hands !
See : My hex offset is 0x37ffed, I take this and convert it to decimal ()10 ... then I get 3669997, which fits our definitions perfectly (7chars).
Now, we have to divide this by the block layer size (512), we get 7167.962890625, which is ugly.
The second one has hex offset at 0x87ffe8, decimal at 8912872, decided by 512 makes 17407.953125
Click to expand...
Click to collapse
Oh, okay, ouch, this sounds like it is going to be a LOT if fun to do . I thought it would be possible because the uodater-script flashes kernels to mmcblk0p4, but I guess that was staging, not the actual kernel partition (this also explains why I got a fliesize if 500ish MB the other day when I dd'ed the partition). Good luck to you, and I will try to help the next time I am bored/have free time.
The important stuff is in the header (raw?) of mmcblk0, so it should be possible to just use dd.
K900 said:
The important stuff is in the header (raw?) of mmcblk0, so it should be possible to just use dd.
Click to expand...
Click to collapse
... so ?
Look at my first post, this is exactly what I did. Stripped off the first 20M and found the offsets. I am getting assistance from Dees_Troy and the TF300 devs to ensure everything is going the right way.
RaymanFX said:
... so ?
Look at my first post, this is exactly what I did. Stripped off the first 20M and found the offsets. I am getting assistance from Dees_Troy and the TF300 devs to ensure everything is going the right way.
Click to expand...
Click to collapse
What I mean is patching the kernel to make it a 'partition' is dangerous and can cause unexpected results, so dd and a modified recovery should be used instead.
K900 said:
What I mean is patching the kernel to make it a 'partition' is dangerous and can cause unexpected results, so dd and a modified recovery should be used instead.
Click to expand...
Click to collapse
Believe me, they can't be used. We need the kernel patch. The guys from tf300 tried anything, but using the kernel hack was the only way to make this possible.
And if (not possible in theory) the hack would cause problems, we can always flash a different one since the /staging-flash is not affected at all
RaymanFX said:
Believe me, they can't be used. We need the kernel patch. The guys from tf300 tried anything, but using the kernel hack was the only way to make this possible.
And if (not possible in theory) the hack would cause problems, we can always flash a different one since the /staging-flash is not affected at all
Click to expand...
Click to collapse
There should be other solutions that don't involve uber ugly kernel hacks. I'll see if I can get more info since I have some docs regarding the boot process on generic Tegra boards and reusing same methods (likely bypassing ASUS bootloaders altogether) should be possible, at least now that we have nvflash access for all.
Hey Rayman, any word on this getting up and going? It will kick tail if you do. No more multiple zips then which means more space for me.
According to my research with others in the #asus-transformer channel on Freenode, the correct values are 0x380000 and 0x880000
380000 to decimal becomes: 3670016
3670016 / 512 = 7168 so 7168 is your first offset
880000 to decimal becomes: 8912896
8912896 / 512 = 17408 so 17408 is your second offset
The difference between the 2 values is hex 500000, decimal 5242880.
5242880 / 512 = 10240 which is your size for both.
Of course, after you build a kernel with the correct source and offsets, you'll want to dd dump the partitions and verify with a hex editor that you're getting the right stuff. Both partitions should start with "ANDROID!". You'll also want to unpack the contents of the dd images with unpackbootimg or something and determine which one is recovery and which one is boot. Most likely the first one is recovery.
Technically some of the other people are right. You can probably use dd with the right seek and size values to flash and dump the partitions without modifying the kernel, but modifying the kernel makes for a cleaner, simpler setup. We've used the kernel approach on the TF201, TF300T, and TF700T with much success.
Hope that helps.
Dees_Troy said:
According to my research with others in the #asus-transformer channel on Freenode, the correct values are 0x380000 and 0x880000
380000 to decimal becomes: 3670016
3670016 / 512 = 7168 so 7168 is your first offset
880000 to decimal becomes: 8912896
8912896 / 512 = 17408 so 17408 is your second offset
The difference between the 2 values is hex 500000, decimal 5242880.
5242880 / 512 = 10240 which is your size for both.
Of course, after you build a kernel with the correct source and offsets, you'll want to dd dump the partitions and verify with a hex editor that you're getting the right stuff. Both partitions should start with "ANDROID!". You'll also want to unpack the contents of the dd images with unpackbootimg or something and determine which one is recovery and which one is boot. Most likely the first one is recovery.
Technically some of the other people are right. You can probably use dd with the right seek and size values to flash and dump the partitions without modifying the kernel, but modifying the kernel makes for a cleaner, simpler setup. We've used the kernel approach on the TF201, TF300T, and TF700T with much success.
Hope that helps.
Click to expand...
Click to collapse
From my research
Code:
Position 3670016 / 512 = 7168
Position 8912896 / 512 = 17408
Diff
5242880
10240
From nvflash flash.cfg
SOS Size 5242880 / 512 = 10240
LNX Size 8388608 / 512 = 16384
Also, I already have a kernel compiled. I'll test later.
Just thinking about this thing and wondering about the linux-based (or are they also based on other architectures?) blob tools as a possible workaround? Ignore this if it seems silly. I haven't thought about this sort of thing for a long time and not at all on the transformer.
-
When any of the many kernel/ROM installer scripts take off and do their thing, they use the compiled (usually for linux, but some sort of combo binary and script) blob tools , I thought from Rayman as well (but it's been awhile since I've played with the source and the tools themselves.
Is there any reason why an android version of those couldn't be built and used inside either cwm or tw* to perform both the backup and retrieval of the kernel? I realize it would have to churn out an installer type script somewhere in the backup directory and run it upon restore, but would something like this be one of the multiple possible solutions? I'm guessing there is some obvious reason I've not looked into yet, like a dependency upon some other API or utility that is in a full linux system, but not in an android OS.. (but I don't know).
I suppose the good news of this would be that numbers tied to the partition wouldn't be of much importance since blobbing works OK without them, but there might also be a down side to adding a completely different type of backup/restore paradigm just for the kernel to a nice little piece of code (cwm/tw*) that works for everything else.
hachamacha said:
Just thinking about this thing and wondering about the linux-based (or are they also based on other architectures?) blob tools as a possible workaround? Ignore this if it seems silly. I haven't thought about this sort of thing for a long time and not at all on the transformer.
-
When any of the many kernel/ROM installer scripts take off and do their thing, they use the compiled (usually for linux, but some sort of combo binary and script) blob tools , I thought from Rayman as well (but it's been awhile since I've played with the source and the tools themselves.
Is there any reason why an android version of those couldn't be built and used inside either cwm or tw* to perform both the backup and retrieval of the kernel? I realize it would have to churn out an installer type script somewhere in the backup directory and run it upon restore, but would something like this be one of the multiple possible solutions? I'm guessing there is some obvious reason I've not looked into yet, like a dependency upon some other API or utility that is in a full linux system, but not in an android OS.. (but I don't know).
I suppose the good news of this would be that numbers tied to the partition wouldn't be of much importance since blobbing works OK without them, but there might also be a down side to adding a completely different type of backup/restore paradigm just for the kernel to a nice little piece of code (cwm/tw*) that works for everything else.
Click to expand...
Click to collapse
That would be an option as well I suppose. Take the image and call blobpack and build a blob to be flashed on reboot. Although, if we could 'dd' it cleanly without causing issues with other devices, that would be an ideal solution. Until then, this kernel change will work.
Hi guys.
Several months ago, I have bought a rk2918 based tablet and succesfully rooted it as you can see in this thread. I haven´t managed to take the time and have more fun with this tablet until today, when I decided to tweak it a bit. So, I´m facing a bit of a problem and don´t know how to solve it. I wan´t to create a custom partition layout, in other words - I want to increase data and system partitions on this tablet. So if anybody understands mtd partitioning I would be grateful for any help. So here´s the current partition layout:
Code:
0[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](backup),
[email protected](cache), 112,4 MB
[email protected](userdata), 504 MB
[email protected](kpanic),
[email protected](system) 247 MB,
[email protected](user) 2.58 GB
So, I want to decrease "user" partition for 1024 MB, increase "userdata" partition for 950 MB and increase "system" partition for 74 MB. If someone understands how to do it, I would really appreciate it!
Anybody? I´m just refreshing this thread so people can notice it..
Root protab25
Sirrocco, could you make a root rights on this rom: Firmware Update TAB-PROTAB25 model 2.2_2.3 NOT for other versions.zip 179 MB
Please go to the link itself, I was a novice user can not post URL downloads.pointofview-online.com
The format is [email protected]
so if you want to increase size of userdata by 950MB you need to add 950×2048 which is in hexa 1DB000 to size of [email protected](userdata) which is
[email protected](userdata)
add same value to position of all following partitions (kpanic, system, user).
last partition is specified only by starting position and uses rest of memory so you don't need to worry about it's size
[email protected](user)
Ficik said:
The format is [email protected]
so if you want to increase size of userdata by 950MB you need to add 950×2048 which is in hexa 1DB000 to size of [email protected](userdata) which is
[email protected](userdata)
add same value to position of all following partitions (kpanic, system, user).
last partition is specified only by starting position and uses rest of memory so you don't need to worry about it's size
[email protected](user)
Click to expand...
Click to collapse
Omg, thank you man! Cheers! :highfive:
See Post #2 for current known stock partition parameters for various devices. Your contributions for missing devices are welcome and appreciated. Cheers!
Introduction
This guide / reference aims to be a complete article on customizing, resizing and/or re-ordering the internal partition layout on most (any?) Android MTD-based device. I have seen many questions around the various forums on how to get more internal data so I thought I'd share my developments. Hopefully this will become a valuable resource for kernel builders/hackers.
The guide is especially valuable (and, in the case of my kernel builds, originally designed for) the Xperia 2011 line, but from what I know it could be applied to nearly any Android device where kernel source/flashing is possible.
I would like to gather stock partition information for various devices and place them into Post #2. If you can at least give me your Partition Info from ATAG (see "Gathering information" section), I can create a reference for all kernel developers. Thank you!
Requirements
Android SDK
Ability to build a kernel (this guide does not teach that)
Ability to flash a kernel (unlocked bootloader, etc)
Bootloader which exposes Partition info via ATAG on startup (see "Gathering information" section)
Device which uses MTD Partition Map (Don't know how to check this, I think most Android devices do anyway)
Warning
As far as I know, following this guide and using precise calculation that you double and triple check before flashing will not result in a hard brick - however I can not guarantee it. Some devices may have "obscure" partition maps or some "protected" sectors for one reason or another, and modifying these *may* result in either a hard-brick (unlikely) or a permanent inability to restore your device to 100% stock (very likely) for warranty and/or DRM purposes. You have been warned. I/we/anyone may not be held accountable for any of these events should they occur, for you are doing this at your own risk and with your own responsibility.
Gathering information
The first thing you'll want to do for the sake of accuracy is to flash to a 100% stock firmware. In the case of Xperia 2011 devices, flash the latest stock FTF for your device.
With the stock firmware now installed, the second thing you will need to do is to flash a custom kernel that is rooted and has busybox installed. In most cases, a CM7/9/10 kernel will do nicely.
Power-off your device. Execute the following command from shell/console, and then press enter:
Code:
adb wait-for-device && adb shell dmesg
After pressing enter, the console will wait at the prompt as intended. Now, power on your device and immediately plug in the USB cable. I assume the ADB drivers are already installed.
Shortly (5-15 seconds) you should see a mass output from the kernel followed by a return to your shell prompt. If you don't, either your kernel or bootloader does not support it. Try a different kernel. If you still don't, then sorry but I think we can't do it for your device.
Scroll right to the top of the dmesg output, you should see something similar to this:
Code:
<6>[ 0.000000] Initializing cgroup subsys cpu
<5>[ 0.000000] Linux version 2.6.32.9-KRsH ([email protected], Linaro 4.7) (gcc version Linaro 4.6.2 20111004) #8 PREEMPT Thu Oct 25 15:57:27 EST 2012
<4>[ 0.000000] CPU: ARMv7 Processor [511f00f2] revision 2 (ARMv7), cr=10c53c7d
<4>[ 0.000000] CPU: VIPT nonaliasing data cache, VIVT ASID tagged instruction cache
<4>[ 0.000000] Machine: zeus
<6>[ 0.000000] Partition (from atag) system -- Offset:2e4 Size:9c4
<6>[ 0.000000] Partition (from atag) userdata -- Offset:ca8 Size:be0
<6>[ 0.000000] Partition (from atag) cache -- Offset:1cb4 Size:32c
<6>[ 0.000000] Partition (from atag) appslog -- Offset:1888 Size:42c
<4>[ 0.000000] Memory policy: ECC disabled, Data cache writeback
...see those "Partition (from atag)" lines? That's what we need! Copy this information down and move on to the next section.
Additional verification and hidden partitions (optional)
As far as I know, this is only possible with Xperia 2011 devices. If you know of a method for other devices, please let me know.
We can additionally verify the ATAG information and map extra "hidden" partitions such as boot (kernel) by examining the SIN files inside an FTF. I will assume that you know how to use Flashtool already as I won't go into much detail here.
First, we need to enable the development features of Flashtool. In the program folder, open "config.properties" and edit/add the line like so:
Code:
devfeatures=yes
Next, extract your stock FTF bundle with any ol' ZIP extractor, load Flashtool, and select "Tools" > "SIN Editor", and open a particular SIN file that you want to verify/unhide. In this example, we will open system.sin. The "Partition Info" field is what we want. Behold:
Code:
STOCK SIN:
system: 0400000001000080E4020000C4090000
-- --|------||------|
| | | |
type? (elf/yaffs) _/ | | \____ byte-reversed size
| |
unknown ____/ \____________ byte-reversed offset
The second last 8-bytes are the offset and the last 8-bytes are the size. By "byte-reversed" I mean that you read each byte from end to beginning, but not swap the bytes themselves. Thus the size above, reading "C4090000" is actually "000009C4". And as you can see, this matches 100% to our ATAG of 9c4 for system size. Correct sir! Additionally, the offset of "E4020000" > reversed to "000002E4" also matches.
So now, we can open "kernel.sin" and do the same, because we also want to partition "boot" (why not?). In this device (Xperia Play/Xperia Neo L), kernel.sin gives us 03000000220000808002000064000000 which means that the size is 64 and the offset is 280.
Calculations
From the partition info via ATAG, we can now build "stock" mtdparts information to apply to our kernel. Using the example(s) above, we can now build this information:
Code:
system : [email protected]
userdata : [email protected]
cache : [email protected]
appslog : [email protected]
boot : [email protected]
Note the syntax of size@offset. Next, we must convert the hex values to decimal, then multiply by 128 (I do not know if 128 is the same multiplier for all devices, please double check and let me know). This will give us the exact sizes and offsets in kilobytes.
Code:
system : [email protected]
userdata : [email protected]
cache : [email protected]
appslog : [email protected]
boot : [email protected]
Alright, so that is a 100% stock partition map for this device - except we also have the boot (kernel) mapped now too. Here is a (crappy) visual representation of it:
Code:
reserved | boot | /system | /data | appslog | /cache |
first 80MB | 12.5MB | 312.5MB | 380MB | 133.5MB | 101.5MB |
Note: Not to scale :)
You may have noticed that the order we (and ATAG) lists the partitions in does not match the actual order of the partitions. It is quite important to retain the order of the partitions as specified in ATAG, because that's the order they will be mapped in. I.e. system will remain mtdblock0 and cache will remain mtdblock2. Any extra partitions should always go after these defaults.
Formatting for kernel
To specify the mtdparts parameter for the kernel to use is trivial. Doing this will over-ride the ATAG map (from bootloader) and everything in the system - including Recovery - will see your map from the kernel. Search your default config file in your kernel for the value "CONFIG_CMDLINE" and you should find a value like this :
Code:
CONFIG_CMDLINE="console=ttyMSM2,115200n8 androidboot.hardware=semc"
Using the information we have above about our partition map, we add a new parameter here with "mtdparts=msm_nand:". The syntax is as follows:
Code:
mtdparts=msm_nand:[size]@[offset](name){,[size]@[offset](name)}{...}
Remember that we converted our size and offsets to kilobytes (for better readibility) so we need to specify size unit of k. The new parameter, from our above examples, becomes this:
Code:
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)
Don't forget to retain the order! And so, our full line looks like this:
Code:
CONFIG_CMDLINE="console=ttyMSM2,115200n8 androidboot.hardware=semc mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)"
NOTE: Depending on your kernel, you may also need to enable the following line in your config:
Code:
CONFIG_MTD_CMDLINE_PARTS=y
And we're all done. If you build your kernel now, you will be able to mount (or at least dd from) the appslog and boot partitions.
Resizing partitions
This is somewhat trivial, the most difficult part is probably over - but this step can be tedious, albeit not very complicated. Anybody with an above average IQ would have already figured this out - we simply change the size of one partition and adjust the offsets of it's following partitions to accommodate for the change. Here is one good example that I use for the MIUI ROM for the Xperia Play and Neo L, compared to the stock examples shown above:
Code:
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)
...and a visual representation of this new map:
Code:
reserved | boot | /system | /data |/cache|
first 80MB | 12.5MB | 280MB | 639MB | 8MB |
Note: Not to scale :)
Hopefully that's enough to make sense. Remember to verify your modified partitions. This can easily be done by adding the size+offset of a partition, giving the offset of the next partition. E.g. in this mod, userdata ends at 1036288 (654848+381440) which matches the offset for the next partition - cache.
Troubleshooting/Recovering from modified partitions
In some cases, your new kernel may not boot. A common issue is that the kernel logo will show, and the device will shortly reboot (kernel bootloop). This can be solved by formatting your partitions with fastboot after flashing the new kernel, usually system and userdata are all that is needed:
Code:
fastboot format system
fastboot format userdata
If you wish to return to a stock partition layout, sometimes flashing a non-modified kernel is not enough. You may get stuck on kernel logo even after formatting system and userdata. In this case, flashing a stock Firmware and setting your phone back to scratch should result in a 100% original device. But if your phone is still bricked, sorry but it's not my fault. You probably did something wrong.
#####
OK, that's the guide done for now. Any questions or suggestions on the guide, please let me know! Also, refer to post #2 for some stock partition map reference.
Finding Stock Partition Info For Your Device
Three methods:
Most reliable - See the section "Gathering info" above to get it from ATAG
Only shows size without offset - do "cat /proc/mtd" from adb shell. Can be used to test if you're on stock partitions or not, or to verify partition is big enough for update ZIP's (with sed/grep).
Xperia 2011 Only - Examine SIN header as outlined above. This method is difficult to determine mtd block order but I'm 99% sure the order is same for all Xperia 2011 devices (system=mtd0, userdata=mtd1, cache=mtd2).
Stock Partition Parameters for Various Devices
Xperia 2011 Range:
Code:
[B]anzu (Arc) (LT15) (HDPI):[/B]
(03) kernel - [email protected] ([email protected]) (unmapped)
(04) system - [email protected] ([email protected])
(05) amss - [email protected] ([email protected]) (unmapped)
(06) amss_fs - [email protected] ([email protected]) (unmapped)
(08) adsp - [email protected] ([email protected]) (unmapped)
(09) userdata - [email protected] ([email protected])
(10) vendor - [email protected] ([email protected])
(0B) fota0 - [email protected] ([email protected]) (unmapped)
(0C) fota1 - [email protected] ([email protected]) (unmapped)
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](appslog),[email protected](amss),[email protected](amss_fs),[email protected](adsp),[email protected](fota0),[email protected](fota1),[email protected](boot)
[B]ayame (Arc S) (LT18) (HDPI):[/B]
(03) kernel - [email protected] ([email protected]) (unmapped)
(04) system - [email protected] ([email protected])
\ this is odd, there is 2048k unallocated between boot and system (SEMC made a mistake?)
(05) amss - [email protected] ([email protected]) (unmapped)
(06) amss_fs - [email protected] ([email protected]) (unmapped)
(08) adsp - [email protected] ([email protected]) (unmapped)
(09) userdata - [email protected] ([email protected])
(10) vendor - none
(0B) fota0 - [email protected] ([email protected]) (unmapped)
(0C) fota1 - [email protected] ([email protected]) (unmapped)
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot),[email protected](amss),[email protected](amss_fs),[email protected](adsp),[email protected](fota0),[email protected](fota1)
[B]haida (Neo V) (MT11) (HDPI):[/B]
[I]Same as ayame (Arc S) (LT18)[/I]
[B]hallon (Neo) (MT15) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]
[B]iyokan (Pro) (MK16) (HDPI):[/B]
[I]Same as ayame (Arc S) (LT18)[/I]
[B]mango (Mini Pro) (SK17) (MDPI):[/B]
??
[B]satsuma (Active) (ST17) (MDPI):[/B]
??
[B]smultron (Mini) (ST15) (MDPI):[/B]
??
[B]urushi (Ray) (ST18) (HDPI):[/B]
??
[B]phoenix (Neo L) (MT25) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]
[B]zeus/zeusc (Play) (R800) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]
R800a (and probably i/at, but not x) has unallocated vendor partition. Needs one-time flash of Vendor-enabled FTF (e.g. phoenix or anzu) to allocate it otherwise the vendor map will present I/O errors.
Reserved again (just in case)
Thanks for the info. You have used the same for MIUI for Neo L and Play and we have good internel memory..
Thanks for sharing
Very nice work mate! (Especially for using ATAGs...)
I just started the related thread:
"[DEV][REF] El Grande Partition Table Reference"
To collect detailed partition info from various devices...
E:V:A said:
Very nice work mate! (Especially for using ATAGs...)
I just started the related thread:
"[DEV][REF] El Grande Partition Table Reference"
To collect detailed partition info from various devices...
Click to expand...
Click to collapse
Heh nice! Yours looks a bit more hardcore than mine, I've never used any of those tools
I started this guide so I can port kernels to various devices for Xperia 2011 range, and also to help other devs appeal the users who crave for more internal partition space. But so far, none of these people seem to have the patience to lend a hand with gathering data
Xperia Arc (anzu - LT15i_4.1.B.0.587_Generic Global World)
Code:
SIN name HEX [email protected] DEC (in k) SIZE
amss.sin: ??? E4 @ 10 29184 @ 2048 28Mb
amss_fs_anzu.sin: ??? 68 @ F4 13312 @ 31232 13Mb
adsp.sin: ??? 6C @ 15C 13824 @ 44544 13Mb
fota0.sin: ??? 5C @ 1C8 11776 @ 58368 11Mb
fota1.sin: ??? 5C @ 224 11776 @ 70144 11Mb
kernel.sin: boot 64 @ 280 12800 @ 81920 12Mb
system.sin: system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata.sin: userdata BE0 @ CA8 389120 @ 414720 380Mb
vendor.sin: vendor 42C @ 1888 136704 @ 803840 133Mb
I've been talking to wedgess about the use of the cache partition... been poking around and he pointed me in your direction... so, here we go! :highfive:
[NUT] said:
Xperia Arc (anzu - LT15i_4.1.B.0.587_Generic Global World)
Code:
SIN name HEX [email protected] DEC (in k) SIZE
amss.sin: ??? E4 @ 10 29184 @ 2048 28Mb
amss_fs_anzu.sin: ??? 68 @ F4 13312 @ 31232 13Mb
adsp.sin: ??? 6C @ 15C 13824 @ 44544 13Mb
fota0.sin: ??? 5C @ 1C8 11776 @ 58368 11Mb
fota1.sin: ??? 5C @ 224 11776 @ 70144 11Mb
kernel.sin: boot 64 @ 280 12800 @ 81920 12Mb
system.sin: system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata.sin: userdata BE0 @ CA8 389120 @ 414720 380Mb
vendor.sin: vendor 42C @ 1888 136704 @ 803840 133Mb
I've been talking to wedgess about the use of the cache partition... been poking around and he pointed me in your direction... so, here we go! :highfive:
Click to expand...
Click to collapse
Awesome, thanks for the partition info. I *hope* to get all Xperia 2011 device info so I can build Turbo Kernel for all. From what I can see, Arc partitions are identical to Play and Neo L. So maybe all Xperia 2011 devices are the same.
Since the cache partition is not an FTF file, it goes after vendor - so offset would be 940544 (kb). The size I am not sure and might vary per device. /proc/mtd (or /proc/partitions) should tell you.
Also, you can remove vendor partition - because all ROM's just mount it to the folder at /system/vendor so any vendor files you need can go into system partition, and then you can remap/reclaim vendor.
CosmicDan said:
Awesome, thanks for the partition info. I *hope* to get all Xperia 2011 device info so I can build Turbo Kernel for all. From what I can see, Arc partitions are identical to Play and Neo L. So maybe all Xperia 2011 devices are the same.
Since the cache partition is not an FTF file, it goes after vendor - so offset would be 940544 (kb). The size I am not sure and might vary per device. /proc/mtd (or /proc/partitions) should tell you.
Also, you can remove vendor partition - because all ROM's just mount it to the folder at /system/vendor so any vendor files you need can go into system partition, and then you can remap/reclaim vendor.
Click to expand...
Click to collapse
Might be different for the Arc S (ayame) ... i'm looking into the official firmware release now to confirm... but as i used a FTF for my LT15i to gain size on my userdata a while back this is what i get from the dmesg ATAG lines...
Code:
system 9C4 @ 2E4 320000 @ 94720 312Mb
cache 32C @ FA4 103936 @ 512512 101Mb
userdata D20 @ 12D0 430080 @ 616448 420Mb
Seeing cache between system and userdata ... but no vendor partition anymore
I also notice my endpoint at 918Mb of 1000MB (as sony states in their whitepaper: 1GB) that would be inside the phone ... lost space or do you know a reason perhaps?
[NUT] said:
Might be different for the Arc S (ayame) ... i'm looking into the official firmware release now to confirm... but as i used a FTF for my LT15i to gain size on my userdata a while back this is what i get from the dmesg ATAG lines...
Code:
system 9C4 @ 2E4 320000 @ 94720 312Mb
cache 32C @ FA4 103936 @ 512512 101Mb
userdata D20 @ 12D0 430080 @ 616448 420Mb
Seeing cache between system and userdata ... but no vendor partition anymore
I also notice my endpoint at 918Mb of 1000MB (as sony states in their whitepaper: 1GB) that would be inside the phone ... lost space or do you know a reason perhaps?
Click to expand...
Click to collapse
1GB = 1024MB, not 1000MB
Well on stock zeus/phonex, as the OT shows, boot + system + data + appslog (vendor) + cache = 940MB. Along with the ~80MB of reserved data at the beginning for radio/baseband and such, that comes to 1020MB. I assume the last missing ~4MB of the full 1GB is reserved for remapping bad blocks (i.e. wear-leveling).
That FTF is completely weird, just like the 420MB space mod for some devices is actually dangerous (size of one partition overlaps the offset of another by about 20MB). If you visualize your map you just showed, there is some wasted space after /system map. Anyway, the cache partition on zeus board goes right at the end, after vendor. So yeah the maps are obviously different, however I think the 1020MB NAND size is possibly the same for all msm-7x30/Snapdragon S2 SoC devices (not just Sony).
Could you ensure you have flashed a 100% original/genuine FTF file and get full ATAG information again?
CosmicDan said:
1GB = 1024MB, not 1000MB
Click to expand...
Click to collapse
well... thats open for debate in some way, GB != GiB. For me 1GB should be 1024Mb though ...
CosmicDan said:
Well on stock zeus/phonex, as the OT shows, boot + system + data + appslog (vendor) + cache = 940MB. Along with the ~80MB of reserved data at the beginning for radio/baseband and such, that comes to 1020MB. I assume the last missing ~4MB of the full 1GB is reserved for remapping bad blocks (i.e. wear-leveling).
Click to expand...
Click to collapse
most likely yes... sounds fair atleast...
CosmicDan said:
That FTF is completely weird, just like the 420MB space mod for some devices is actually dangerous (size of one partition overlaps the offset of another by about 20MB). If you visualize your map you just showed, there is some wasted space after /system map. Anyway, the cache partition on zeus board goes right at the end, after vendor. So yeah the maps are obviously different, however I think the 1020MB NAND size is possibly the same for all msm-7x30/Snapdragon S2 SoC devices (not just Sony).
Click to expand...
Click to collapse
i've been playing around with wedgess' kernel:
Code:
system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata 1258 @ CA8 601088 @ 414720 587Mb
cache 40 @ 1F00 8192 @ 1015808 8Mb
EOD: 1024000 1000Mb
Thats what i am using now, thanks to your guide
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
CosmicDan said:
Could you ensure you have flashed a 100% original/genuine FTF file and get full ATAG information again?
Click to expand...
Click to collapse
Will report back with the defaults from the stock rom later... going to bed now... 7:36am here now... haven't been sleeping yet :silly:
Yeah true, the whole kilobyte/kibibyte thing.... they still display KB/MB instead of KiB/MiB in most things even though they're in 1024 unit (shell listings, file explorer properties, etc.) but storage vendors do use true 1000 units, 32GB SDCard for example... but then the software doesn't so it's stupid and confusing So yeah, most people have not adopted it, thus it's better to assume that all KB/MB/etc measurements are done in powers of 1024 still.... because they're old school
I wonder, in pther Android ROM's is it corrrect? In MIUI/Turbo UI it shows 639MB in Storage (instead of MiB) so I assume even Android OS itself is also "wrong" haha. Titanium Backup is the *only* app I know of that shows sizes in power of 1000.... and that confuses a lot of people.
CosmicDan said:
Yeah true, the whole kilobyte/kibibyte thing.... they still display KB/MB instead of KiB/MiB in most things even though they're in 1024 unit (shell listings, file explorer properties, etc.) but storage vendors do use true 1000 units, 32GB SDCard for example... but then the software doesn't so it's stupid and confusing So yeah, most people have not adopted it, thus it's better to assume that all KB/MB/etc measurements are done in powers of 1024 still.... because they're old school
I wonder, in pther Android ROM's is it corrrect? In MIUI/Turbo UI it shows 639MB in Storage (instead of MiB) so I assume even Android OS itself is also "wrong" haha. Titanium Backup is the *only* app I know of that shows sizes in power of 1000.... and that confuses a lot of people.
Click to expand...
Click to collapse
Code:
SIN name HEX [email protected] DEC (in k) SIZE
amss.sin: ??? E4 @ 10 29184 @ 2048 28Mb
amss_fs_anzu.sin: ??? 68 @ F4 13312 @ 31232 13Mb
adsp.sin: ??? 6C @ 15C 13824 @ 44544 13Mb
fota0.sin: ??? 5C @ 1C8 11776 @ 58368 11Mb
fota1.sin: ??? 5C @ 224 11776 @ 70144 11Mb
kernel.sin: boot 64 @ 280 12800 @ 81920 12Mb
LT15i: anzu
system.sin: system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata.sin: userdata BE0 @ CA8 389120 @ 414720 380Mb
vendor.sin: vendor 42C @ 1888 136704 @ 803840 133Mb
cache 330 @ 1CB4 104448 @ 940544 102Mb
EOD: 1044480 1020Mb
LT18i: ayame
system.sin: system C80 @ 2F4 409600 @ 96768 400Mb
cache 360 @ 1CB4 110080 @ 506368 107Mb
userdata.sin: userdata D20 @ 12D0 430080 @ 616448 420Mb
EOD: 1046528 1022Mb
MK16i/a: iyokan
system.sin: system C80 @ 2F4 409600 @ 96768 400Mb
cache 360 @ 1CB4 110080 @ 506368 107Mb
userdata.sin: userdata D20 @ 12D0 430080 @ 616448 420Mb
EOD: 1046528 1022Mb
your welcome
Great thanks. It seems the anzu has 2MB unused... is that your device? If so, do you know how to use dd? Can use dd to dump partition, if its mapped bad it will give I/O error.
Sent from Xperia Play (R800a) with Tapatalk
CosmicDan said:
Great thanks. It seems the anzu has 2MB unused... is that your device? If so, do you know how to use dd? Can use dd to dump partition, if its mapped bad it will give I/O error.
Sent from Xperia Play (R800a) with Tapatalk
Click to expand...
Click to collapse
Yep, I have the anzu, and I know how to use dd... Will test that some time later would it be possible to dump all of the nand flash?
Sent from my LT15i using xda app-developers app
[NUT] said:
Yep, I have the anzu, and I know how to use dd... Will test that some time later would it be possible to dump all of the nand flash?
Sent from my LT15i using xda app-developers app
Click to expand...
Click to collapse
Sure, should be. Say you wanted to dump entire flash to one image, just add another partition to mtdparts parameter with offset 0 and size of 1020MB (in anzu case). Then you can dd from that new mtdblock device to sdcard. But I think you may get lots of I/o errors on the first 80MB, I am really not sure. Just make sure you don't try to write to it LOL.
Also I think our devices need bs=4096 (4KB) because that is the sector size of our nand chip.
EDIT: Maybe there is some unused space at the end of that first 80MB, I am not sure. Because baseband and adsp firmware is less than 80MB.
Sent from Xperia Play (R800a) with Tapatalk
CosmicDan said:
Sure, should be. Say you wanted to dump entire flash to one image, just add another partition to mtdparts parameter with offset 0 and size of 1020MB (in anzu case). Then you can dd from that new mtdblock device to sdcard. But I think you may get lots of I/o errors on the first 80MB, I am really not sure. Just make sure you don't try to write to it LOL.
Also I think our devices need bs=4096 (4KB) because that is the sector size of our nand chip.
EDIT: Maybe there is some unused space at the end of that first 80MB, I am not sure. Because baseband and adsp firmware is less than 80MB.
Sent from Xperia Play (R800a) with Tapatalk
Click to expand...
Click to collapse
From what i know from using dd: it does a byte4byte copy, in any sector size you like but in any case it will read what the disk says there is, as long as there is a disk... so the o/i errors should only occur on those parts that are either damaged or non existent...
I'll do a partition as last option in the config_cmdline grabbing the theoretical maximum of 1024Mb and see if it will fly.
As the NAND flash chip has no logic that makes it a disk like entity other then direct access through MTD software logic (hence yaffs2 as filesystem of choice) i strongly doubt it will use the last 2/4Mb in the end as wear leveling buffer...
[NUT] said:
I'll do a partition as last option in the config_cmdline grabbing the theoretical maximum of 1024Mb and see if it will fly.
Click to expand...
Click to collapse
Well... it doesn't ... it craps out on the first sector it seems, but even if i skip the first sector it still doesn't want to go, probably because the partition size was wrong in the first place, but it's strange anyway.
Building a new testkernel with [email protected] which is one less in size, if 0 counts as the first, the last probably didn't exist
EDIT: nope, that one didn't fly either... dunno why, dd isn't very elaborate on it's errors
[NUT] said:
Well... it doesn't ... it craps out on the first sector it seems, but even if i skip the first sector it still doesn't want to go, probably because the partition size was wrong in the first place, but it's strange anyway.
Building a new testkernel with [email protected] which is one less in size, if 0 counts as the first, the last probably didn't exist
EDIT: nope, that one didn't fly either... dunno why, dd isn't very elaborate on it's errors
Click to expand...
Click to collapse
I think that beginning part is "read-protected" in userspace, I'm not sure. I will def. like to try this but my linux machine is awaiting repairs, I want to see if I can write to the amss (SBL) partition. Probably not though
CosmicDan said:
I think that beginning part is "read-protected" in userspace, I'm not sure. I will def. like to try this but my linux machine is awaiting repairs, I want to see if I can write to the amss (SBL) partition. Probably not though
Click to expand...
Click to collapse
I would agree with you, except if I skip the first 92 Mb of the NAND with dd it still doesn't read... maybe the 'read-protection' foils that plan as well... I don't know ...
Maybe you already have a loader for Qualcomm "Emergency DownLoad" (EDL) mode.
Maybe you're looking for one.
You know what? A single loader is for more than one device. But it gets hairy with signing and manufacturers and stuff.
So, I've got a beta release utility here. It can (in most cases) identify which model Qualcomm processors a "Firehose" loader is designed for.
First, it's currently a Windows release.
Second, it doesn't work with the older .mbn style loader (since they don't include that information).
So, just go to My EDL page and go to the bottom and download qcomview.exe
Code:
C:\>qcomview.exe poke3.bin
APQ8096
APQ8098
MDM9250
MDM9255
MDM9350
MDM9650
MDM9655
MSM8996
MSM8997
MSM8998
QDF2432
SDA630
SDA636
SDA658
SDA660
SDM636
SDM658
SDM660
You can see the SDM 636 (which is the actual processor on a Poke3.
Obviously, you have to select your own loader.
I've scanned through 200 loaders and I recognize all the processors.
If you see a "???" please quote it.
Edit: Maybe you're saying, "That ain't nothing but a "string" script!" Eh, mostly, but it is more clever and it sorts things.
Thanks for the tool. I have a small feature request, since xbl and elf firehorse programmer use similar structure(I guess), it would be useful if you add a way to check if xbl and programmer are compatible(by comparing cert hashes?).
HemanthJabalpuri said:
It would be useful if you add a way to check if xbl and programmer are compatible...
Click to expand...
Click to collapse
It would be.
On your device you already have a ton of ELF images that have compatible signing.
The problem is, the certs are not identical since the lowest level (farthest away from the root authority) has things like dates and annotations and the bit fields are not the same.
I've not yet figured out how to generate from an ELF file the 256 bit "Hash" that EDL gets out of the device.
To those who don't know yet, I've added more things to this utility. It can check the regular hashes in the ELF files. If your device is not SecureBoot this can be handy if you want to patch. The hashes on the program segments in an ELF file are always checked, the signing is only checked if SecureBoot is on. So, if your SecureBoot is off, you can patch a file, run qcomview /h whatever.elf. As of now it won't can correct wrong hashes but you can simply hexedit in the bigendian values and then double-check with the same command.
Code:
C:\>qcomview /h xbl
64 bit ELF, SHA384
0 00000000 000003f8 8a46a864b9bec352 69b1dadfcac64bfa a388f7bea37d855e 50f55170277c043c 87c862e23709fd96 34bb545ac49a3d64 OK
1 00001000 00001cd8
2 0005cd10 00002ab0 3d2e7c505458e1e7 9070b1957a8f2520 3bbcf288674548f1 7db146a86b314499 5890e1432dbac635 2bad53bfd2960908 OK
3 0005f7c0 00000d64 ac556708059a1315 41e774e34310b89f 3c3f13183b43fda9 9e3a34bd0899da4b bb43c1080a43925f fd8d6a2ecd864e29 OK
4 00076d70 00000000
5 0005cd10 00000000
6 00003000 0004cd04 a81ab8ec59e2dfb1 f2f98e3ac0a9a396 1cd9f0dfb5a5daa5 2cda2f52d4df97c8 bc398b24528fd10f cd47ced08596f61c OK
7 0004fd10 00000000
8 0004fd10 0000d000 e7d03abb34361774 e030039e096b3e25 64519024c5c15666 efecbd8006deaaae b87884e2bdab52cb e06a4a7a4873e1c5 OK
9 0005cd10 00000000
10 00060530 00016838 2ca0423b6e745b5f c69544b947556ff1 9d04792c579d2f53 d480d2fa738cac82 1674ddaab8078071 648cc10f384ec25a OK
11 00376d70 00022000 18bdbbdeac3e92c0 6f3e5f06f5aa91ae d0daa757a375bab6 5e90d4e2a52d8e95 2255d80c76637316 b24736223e0a0bd2 OK
12 0005cd10 00000000
13 00398d70 00048ded 794528234b46757a 3017481198fa8fd6 c9578e6565ec301a f0ab28fbe105c460 c7cc855f93576767 29302c26357a00bb OK
14 003e8490 00000000
15 003e1b60 0000692d 1354b9b55447ffb8 54ea17d1d9f1ea88 c84bd1045a6bd106 3b38df93fa049fa9 c1b245dc6106098a 0450a75bf7e5ce3f OK
16 00076d70 00300000 7341f2cde09d6a5f 53bcb90714f779a5 53c3ffeeff1824e5 437464f4bfcc545f 6719370d5d6c656d df96e81382315405 OK
For you Motorola users running into "range restricted" you can dump the ranges by:
Code:
C:\>qcomview /r motog.bin
Addr LUN Start Count
------ --- -------- --------
008220 0 0 32
008238 0 -5 5
008250 1 0 32
008268 1 -5 5
008280 2 0 32
008298 2 -5 5
0082b0 3 0 32
0082c8 3 -5 5
0082e0 4 0 32
0082f8 4 -5 5
008310 5 0 32
008328 5 -5 5
008340 1 0 2048
008358 2 0 2048
008370 3 0 2356
008388 5 0 2356
0083a0 0 2080 512
0083b8 0 0 256
0083d0 0 -33 33
0083e8 0 131072 284992
008400 0 416064 2048
008418 1 1 1
The UFS table is on top, followed my the eMMC table.
HemanthJabalpuri said:
It would be useful if you add a way to check if xbl and programmer are compatible (by comparing cert hashes?).
Click to expand...
Click to collapse
I've just added SHA256 fingerprint of the root CA to qcomview.
Code:
C:\>qcomview /f loader.bin
5adc6039 dcb297d4 0c55df73 1580248d a9e18b31 ccc43b45 36795313 f82fd430
If SecureBoot is enabled xbl/abl/Firehose must all have the same fingerprint.
(This also goes for the other two dozen ELF files in flash.)
For most devices this SHA256 will be the same that your EDL client prints out as "Hash".
There appears to sometimes be (on newer devices?) a discrepancy between root CA fingerprint and EDL "Hash".
Possibly the EDL "Hash" is the encrypted version?
In any case, all the fingerprints should agree.
Renate said:
Maybe you already have a loader for Qualcomm "Emergency DownLoad" (EDL) mode.
Maybe you're looking for one.
You know what? A single loader is for more than one device. But it gets hairy with signing and manufacturers and stuff.
So, I've got a beta release utility here. It can (in most cases) identify which model Qualcomm processors a "Firehose" loader is designed for.
First, it's currently a Windows release.
Second, it doesn't work with the older .mbn style loader (since they don't include that information).
So, just go to My EDL page and go to the bottom and download qcomview.exe
Code:
C:\>qcomview.exe poke3.bin
APQ8096
APQ8098
MDM9250
MDM9255
MDM9350
MDM9650
MDM9655
MSM8996
MSM8997
MSM8998
QDF2432
SDA630
SDA636
SDA658
SDA660
SDM636
SDM658
SDM660
You can see the SDM 636 (which is the actual processor on a Poke3.
Obviously, you have to select your own loader.
I've scanned through 200 loaders and I recognize all the processors.
If you see a "???" please quote it.
Edit: Maybe you're saying, "That ain't nothing but a "string" script!" Eh, mostly, but it is more clever and it sorts things.
Click to expand...
Click to collapse
Hello , Renate
I am using you edl.exe programme. it work fine but i would like to know that the tool has any features to flash using xml file or not ? and it is support ufs provisioning or not ? Please confirm
noob9t2 said:
Please confirm
Click to expand...
Click to collapse
Yes, it does UFS (with the /u flag).
No, it doesn't do these XML files. I find the whole idea a bit overblown.
If you're in the habit of overwriting every partition on your device often, simply:
Take the XML file and delete all the redundant stuff besides 1) partition name, 2) image filename.
Add in edl /w /p on each line.
Execute it as a batch file.
Thank You Renate for reply. we flash ufs chip using qfil after flashing on qfil, we need to flash patch file and check ufs provisioning to boot the device properly. On your tool, anything need to do after writing a partition. if i write a single partition, phone will boot normally ?
noob9t2 said:
If i write a single partition, phone will boot normally?
Click to expand...
Click to collapse
Sure, if you didn't break anything.
The reboot command is edl /z
Ha! You motivated me to track down why some devices need you to do that command twice.
I just fixed it.
Download the special Valentine's Day release of edl.exe (from the usual place).
noob9t2 said:
We flash ufs chip using qfil after flashing on qfil?
Click to expand...
Click to collapse
So, if you're using QFIL there's a loader somewhere that you're using. Find it.
Please can you explain how the patch for the loader works
roulo said:
Please can you explain how the patch for the loader works
Click to expand...
Click to collapse
Loaders are made by phone manufacturers from standard editions of xbl (the secondary loader) released by Qualcomm.
Sometimes they put in restrictions (like Lenovo/Motorola), sometimes they put in authorization (like OnePlus).
Sometimes there are two different versions, one with full capabilities, one without.
The word "patched" gets used often for the full capabilities loader.
Patching a loader yourself is not that difficult, the problem is that loaders must be signed and you can't do that.
Many components on Qualcomm SoC phones are signed.
This ensures a "chain of trust".
The only way that you can patch something is if your device does not have SecureBoot enabled.
If you know of a phone without SecureBoot, tell me and I'll buy a case of them.
I never had time but here is a starting point.
https://forum.xda-developers.com/t/k40-bricked.4538285/post-87978383
alecxs said:
I never had time but here is a starting point.
https://forum.xda-developers.com/t/k40-bricked.4538285/post-87978383
Click to expand...
Click to collapse
What I could read of that was talking about analyzing Firehose loaders for vulnerabilities, which you can.
I've largely disassembled a "restricted" Motorola Firehose loader and could patch it easily.
Still, unless some Motorola employee goes rogue I don't see how I could sign it.