210 replies to this topic

[rjm2k]

I've investigated the hungary update a bit to see what may be possible, using PSAS I have loaded the details of the partitions_zte.mbn file and believe it may be possible to alter it.  Below is the dump from PSAS and also the RS232 boot dump that Seb found previously, although I uses the HTC Diamond option in PSAS to analyse the file the details match those found by Seb.  This means that potentially we could alter the file and use the update to alter the partition sizes.  If this is attempted I would suggest doing it on an already broken (eg screen cracked, usb broken etc) device just in case it gets bricked.  Not sure what the best layout would be, we really need some of the unused space in /system handing over to /data, but I'm not sure what the default free space on /system is.  I don't have the necessary hex editing skills but maybe someone wants to give it a go?  In the meantime I'm asking ZTE if they would be willing to provide an update which only alters the partitions rather than everything like the hungarian update does, if they say yes then we will need to agree on a preferred layout.

partition_zte.mbn

PSAS Partition-Info :
------------------

RECOVERY
---------------------------------------------------------
Page:   0x156
Size:   0x24
Address:  0x02AC0000 - 0x02F40000
Block:   0x00005580 - 0x00005E80
Flash:   0x00000000

BOOT
---------------------------------------------------------
Page:   0x17A
Size:   0x24
Address:  0x02F40000 - 0x033C0000
Block:   0x00005E80 - 0x00006780
Flash:   0x00000000

SPLASH
---------------------------------------------------------
Page:   0x19E
Size:   0xC
Address:  0x033C0000 - 0x03540000
Block:   0x00006780 - 0x00006A80
Flash:   0x00000000

MISC
---------------------------------------------------------
Page:   0x1AA
Size:   0x3
Address:  0x03540000 - 0x035A0000
Block:   0x00006A80 - 0x00006B40
Flash:   0x00000000

CACHE
---------------------------------------------------------
Page:   0x1AD
Size:   0x14A
Address:  0x035A0000 - 0x05EE0000
Block:   0x00006B40 - 0x0000BDC0
Flash:   0x00000000

SYSTEM
---------------------------------------------------------
Page:   0x2F7
Size:   0x67C
Address:  0x05EE0000 - 0x12E60000
Block:   0x0000BDC0 - 0x00025CC0
Flash:   0x00000000

USERDATA
---------------------------------------------------------
Page:   0x973
Size:   0x681
Address:  0x12E60000 - 0x1FE80000
Block:   0x00025CC0 - 0x0003FD00
Flash:   0x00000000

PERSIST
---------------------------------------------------------
Page:   0xFF4
Size:   0xC
Address:  0x1FE80000 - 0x20000000
Block:   0x0003FD00 - 0x00040000
Flash:   0x00000000


Sebs boot

ptn 0 name='recovery' start=00000156 len=00000024 flags=00000000 type=Apps Writable=Yes
ptn 1 name='boot' start=0000017a len=00000024 flags=00000000 type=Apps Writable=Yes
ptn 2 name='splash' start=0000019e len=0000000c flags=00000000 type=Apps Writable=Yes
ptn 3 name='misc' start=000001aa len=00000003 flags=00000000 type=Apps Writable=Yes
ptn 4 name='cache' start=000001ad len=0000014a flags=00000000 type=Apps Writable=Yes
ptn 5 name='system' start=000002f7 len=0000067c flags=00000000 type=Apps Writable=Yes
ptn 6 name='userdata' start=00000973 len=00000681 flags=00000000 type=Apps Writable=Yes
ptn 7 name='persist' start=00000ff4 len=0000000c flags=00000000 type=Apps Writable=Yes

[Krinyo]

This is a really interesting thing, with the low-level hungarian 256-512 update we maybe manage this. I'm really pissed why there is so much wasted space on the /system partition (more than 70 MB!), so its a great idea!
Devs, here is the greatest project!

Edited by Krinyo, 31 December 2010 - 10:08 AM.

[oh!dougal]

The ability to alter partitions would indeed be valuable.
But it does seem to have more potential than most tweaks to "brick" the phone.

Hence two (completely different) question lines ---

1/ Shouldn't the 'Hungarian Update' provide a near-universal de-bricker?
One would hope that the new-image-loader was called from routines that were hard-coded (in permanent old-fashioned rom rather than flash) so that they were un-trashable. While that would be the safe way to design the phone, we don't know whether ZTE did design it that way.
As long as the image-loader is unscathed by the experimental re-flash, I would expect that our Hungarian Helper ought to be able to sort out any accidentally-messed-up partitions. And so, a spare sdcard, with a proven installation of Hungarian Helper ready for action whenever needed, would be a great reassurance when experimentally tweaking partitions ...


2/ Another approach to using 'wasted' free space in /system seems to be to install more apps in /system/apps. Could someone make a simple tool to simplify such installation?
What I have in mind is a clockwork-ready zip that would add *.* from its (image) /system/apps to the (installed) /system/apps. (The /apps folder in the image being supplied empty, for the user to load with her choice of apps.)
Alternatively, one to just replace /system/apps with that from the image zip would still be useful.
This would allow users to more easily tailor (and maximise) their use of /system/apps, and thus their use of the /system space in the unmodified partition layout.
Could someone knock together an apps.zip like this?

Edited by oh!dougal, 31 December 2010 - 10:42 AM.

[rjm2k]

oh!dougal, on Dec 31 2010, 10:38, said:

The ability to alter partitions would indeed be valuable.
But it does seem to have more potential than most tweaks to "brick" the phone.

Hence two (completely different) question lines ---

1/ Shouldn't the 'Hungarian Update' provide a near-universal de-bricker?
One would hope that the new-image-loader was called from routines that were hard-coded (in permanent old-fashioned rom rather than flash) so that they were un-trashable. While that would be the safe way to design the phone, we don't know whether ZTE did design it that way.
As long as the image-loader is unscathed by the experimental re-flash, I would expect that our Hungarian Helper ought to be able to sort out any accidentally-messed-up partitions. And so, a spare sdcard, with a proven installation of Hungarian Helper ready for action whenever needed, would be a great reassurance when experimentally tweaking partitions ...
2/ Another approach to using 'wasted' free space in /system seems to be to install more apps in /system/apps. Could someone make a simple tool to simplify such installation?
What I have in mind is a clockwork-ready zip that would add *.* from its (image) /system/apps to the (installed) /system/apps. (The /apps folder in the image being supplied empty, for the user to load with her choice of apps.)
Alternatively, one to just replace /system/apps with that from the image zip would still be useful.
This would allow users to more easily tailor (and maximise) their use of /system/apps, and thus their use of the /system space in the unmodified partition layout.
Could someone knock together an apps.zip like this?

1. Yes I had considered that this update can provide a universal unbricker, I believe that the Image restore code that is being executed when we hit the key sequence is probably very early on in the chain and probable one of the many "Modem" SBL's so no matter what happens to "User" partitions should always work and always be able to fix a phone.  The only issue I can think of is we don't know that the hungary update will always work for all phones.

2. This is pretty simple anyway it's just a matter of grabbing any existing clockwork update zip and hacking the script, I did this for the gingerbread wifi fix I posted.  I'll attach an example to this post, all you need to do is add the apps you want to /system/app and install using clockwork (I use the old version, don't ask me about the new ones!), you don't even need to sign any more.  If you look into the script commands you can also free up space by removing stuff too (I posted a zip that removed the camera sounds for example).  Putting stuff on /system makes it a bit fiddly to update from the market though.

Attached Files

•  basicappsupdate.zip   46.63K   57 downloads

Edited by rjm2k, 31 December 2010 - 10:57 AM.

[rjm2k]

BIG WARNING

THIS HAS THE POTENTIAL TO KILL YOUR PHONE DO NOT USE UNLESS YOU ARE WILLING TO KILL YOUR PHONE AND MAKE IT USELESS FOREVER

NOT FOR PEOPLE WHO DO NOT UNDERSTAND THE RISKS

I WILL NOT BE HELD RESPONSIBLE IF THIS KILLS YOUR PHONE


Ok, I've hacked the partition_zte file to increase data by 10% and decrease system by 10%, it's attached to this post.  I have NOT tested it, I suggest that if someone has a phone that is damaged (screen, usb etc) that they are willing to brick they try it, otherwise don't!  To use it, download the hungary update and replace the partition_zte.mbn file.  Then run the update.

IGNORE THE ATTACHMENT ON THIS POST SEE LATER POST

Edited by rjm2k, 31 December 2010 - 02:40 PM.

[oh!dougal]

rjm2k, on Dec 31 2010, 10:56, said:

1. Yes I had considered that this update can provide a universal unbricker, I believe that the Image restore code that is being executed when we hit the key sequence is probably very early on in the chain and probable one of the many "Modem" SBL's so no matter what happens to "User" partitions should always work and always be able to fix a phone.  The only issue I can think of is we don't know that the hungary update will always work for all phones.

My expectation would be that a hard-coded primary bootloader would jump to the re-flash code on detecting the button press.
And that this reflash code would be a design foundation -- ZTE would want to avoid changing it if at all possible. If they changed the hardware addressing or the sdcard-reader-chip then they'd have to, but its one of those "working, so don't go near it" low-level functionalities that would be constant throughout the product's lifetime (and probably carried over from one model to the next).
So, if the loader is a constant, the payload format would also be a constant.
The only question then is whether the Hungarian payload is incompatible with any of the hardware variants that we know of.
The stock Hungarian fixer is  fine for both LCD and OLED.
Its known not harmful to the OUK SF with OLED, or the Greek/Hungarian '256' LCD models.  
Obviously there should be considerable doubts about using it with the known-to-be-not-exactly-the-same Japanese variant.
Would there be any expectation of hassles with the 5mp camera? Or the maybe-different compass-accelerometer in the Finnish phones?

Quote

2. This is pretty simple anyway it's just a matter of grabbing any existing clockwork update zip and hacking the script, I did this for the gingerbread wifi fix I posted.  I'll attach an example to this post, all you need to do is add the apps you want to /system/app and install using clockwork (I use the old version, don't ask me about the new ones!), you don't even need to sign any more.  If you look into the script commands you can also free up space by removing stuff too (I posted a zip that removed the camera sounds for example).  Putting stuff on /system makes it a bit fiddly to update from the market though.

I thought this should be fairly easily achieved (even though beyond my own 'android-skillz'), and I'm sure it will be helpful to many.
Would you give it its own thread?

[oh!dougal]

rjm2k, on Dec 31 2010, 12:10, said:

BIG WARNING

THIS HAS THE POTENTIAL TO KILL YOUR PHONE DO NOT USE UNLESS YOU ARE WILLING TO KILL YOUR PHONE AND MAKE IT USELESS FOREVER

NOT FOR PEOPLE WHO DO NOT UNDERSTAND THE RISKS

I WILL NOT BE HELD RESPONSIBLE IF THIS KILLS YOUR PHONE
Ok, I've hacked the partition_zte file to increase data by 10% and decrease system by 10%, it's attached to this post.  I have NOT tested it, I suggest that if someone has a phone that is damaged (screen, usb etc) that they are willing to brick they try it, otherwise don't!  To use it, download the hungary update and replace the partition_zte.mbn file.  Then run the update.

I'd suggest keeping a copy of the stock Hungarian Update handy as being the likeliest way 'back' if the mod does not work first time!

[rjm2k]

Hmm, did a bit more research, the system.img file may need to be re-packed to the correct size but I'm not 100% sure.

[fonix232]

Nope, the system image does not need repacking, it gets written to the partition defined by the partitions MBN file. So if you define another base address, then the flasher (what isn't built in, but probably the amss.mbn, what is actually isn't an MBN file but an ELF binary. I guess the built-in hardware code launches that executable to do the stuff) does it's job.

But, it is important, the /system size must be a bit (2MB will be enough) bigger than the actual size of it! And NO, not the system.img size what you need, but extract it using unyaffs, and that size!

Basically, to-dos:
- Make the SYSTEM partition's end address a bit smaller (needs some logic though)
- re-set USERDATA start address to the new SYSTEM end address.

Check if the file(s) has any kind of checksum, and flash.

Edited by fonix232, 31 December 2010 - 01:30 PM.

[isambard]

i was wondering the exact same thing myself. i'm new to android so need to do a lot of reading up on the boot-up sequence before i can understand how to make the change. hopefully, it can be as simple as changing the size of the partitions and that the boot loader dynamically reads the partition table and boots to a specific partition number/id.

[fonix232]

isambard, on Dec 31 2010, 16:34, said:

i was wondering the exact same thing myself. i'm new to android so need to do a lot of reading up on the boot-up sequence before i can understand how to make the change. hopefully, it can be as simple as changing the size of the partitions and that the boot loader dynamically reads the partition table and boots to a specific partition number/id.

On my old G1, the hboot part was to be edited to accept new partition sizes, and also boot too (to have a new base address to load SYSTEM from, but as in this case it won't get modified, we do not need a new kernel), but I haven't seen anything like hboot in the Blade, normal fastboot mode, and no seen SPL.

By the way, what is the so called PSAS app? Can you link me please?

Edited by fonix232, 31 December 2010 - 02:05 PM.

[rjm2k]

fonix232, on Dec 31 2010, 14:05, said:

On my old G1, the hboot part was to be edited to accept new partition sizes, and also boot too (to have a new base address to load SYSTEM from, but as in this case it won't get modified, we do not need a new kernel), but I haven't seen anything like hboot in the Blade, normal fastboot mode, and no seen SPL.

By the way, what is the so called PSAS app? Can you link me please?

http://psas.revskills.de/

I spotted that amss.mbn was an elf binary, its large but there's text in there that suggests it's based on http://wiki.ok-labs.com/Microkernel

[fonix232]

rjm2k, on Dec 31 2010, 17:19, said:

http://psas.revskills.de/

I spotted that amss.mbn was an elf binary, its large but there's text in there that suggests it's based on http://wiki.ok-labs.com/Microkernel

Maybe it is something like an on-device fastboot, with that special kernel? I mean, in 20MB, you can store EVERYTHING flasher stuff, plus basic system commands, an extended toolbox, etc.

[rjm2k]

I spotted that I hadn't update the page to take account of the new size so here is a new update - this time with a 20% change in size

STILL THE SAME WARNING APPLIES!

Attached Files

•  partition_zte.zip   287bytes   48 downloads

[Krinyo]

Moving apps to /system/app not pratical. /system not a r/w partition, so these apps not upgreadable from market. It's simply wasted space, so we need the modified layout badly.

[isambard]

does anyone who had the original hungarian 256mb rom note the partition table before and after the update? i'm hoping the update automatically does the re-partition, but this might be asking for a lot.

Edited by isambard, 31 December 2010 - 03:18 PM.

[isambard]

hmm. i downloaded and took a look at the image zip. from the files present, my initial theory was that the onboard firmware would re-partition using the partition file and then simply image over the 4 image files into the corresponding partitions.

however, the mystery is the 19mb executable file. i've no idea why there should be such a huge file to achieve this (assuming that this contains the code to do the above) unless it is simply bloat/debug code etc. left inside. i'll have a quick try at disassembling to see if this gives any clues, but strange that this file contains no string references to the partition file or the images - which suggests that this app might not responsible for this imaging work.

[rjm2k]

isambard, on Dec 31 2010, 15:44, said:

hmm. i downloaded and took a look at the image zip. from the files present, my initial theory was that the onboard firmware would re-partition using the partition file and then simply image over the 4 image files into the corresponding partitions.

however, the mystery is the 19mb executable file. i've no idea why there should be such a huge file to achieve this (assuming that this contains the code to do the above) unless it is simply bloat/debug code etc. left inside. i'll have a quick try at disassembling to see if this gives any clues, but strange that this file contains no string references to the partition file or the images - which suggests that this app might not responsible for this imaging work.

yes amss.mbn appears to be an embedded os for the chipset so may not be responsible for the flashing. it may well be that the flashing is done by something onboard and not present in the zip - maybe whatever it is simply looks at whatever is in the image directory and flashes it over

edit - it appears to be oemsbl that refers to the other files so presumably thats doing the flash

Edited by rjm2k, 31 December 2010 - 04:03 PM.

[gingerninja]

Hi
I've just been reading this thread at xda Link
It contains information about resizing partitions on HTC Desire. It's all a bit beyond my knowledge but may be helpfull to somebody who knows what they are doing.

Andy

[isambard]

rjm2k, on Dec 31 2010, 17:00, said:

yes amss.mbn appears to be an embedded os for the chipset so may not be responsible for the flashing. it may well be that the flashing is done by something onboard and not present in the zip - maybe whatever it is simply looks at whatever is in the image directory and flashes it over

edit - it appears to be oemsbl that refers to the other files so presumably thats doing the flash

i had a very quick look at the amss file and i'm guessing this is actually software for the internal modem unit. found the strings in oemsbl so will investigate this file to see what it does.