Partition layout change

[Guest 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

[Guest 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 December 31, 2010 by Krinyo

[Guest 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 December 31, 2010 by oh!dougal

[Guest rjm2k]

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.

basicappsupdate.zip

Edited December 31, 2010 by rjm2k

[Guest 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 December 31, 2010 by rjm2k

[Guest oh!dougal]

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?

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?

[Guest oh!dougal]

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!

[Guest 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.

[Guest 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 December 31, 2010 by fonix232

[Guest 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.

[Guest fonix232]

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 December 31, 2010 by fonix232

[Guest rjm2k]

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

[Guest fonix232]

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.

[Guest 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!

partition_zte.zip

[Guest 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. :(

[Guest 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 December 31, 2010 by isambard

[Guest 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.

[Guest rjm2k]

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 December 31, 2010 by rjm2k

[Guest 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

[Guest isambard]

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.

[Guest rjm2k]

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

Good find, it points to another thread which basically says we can get the kernel to ignore the partitions that were found automatically (ie what partitions_zte.mbn creates) and use a custom scheme. This may be a safer method but would need someone like TomG or KK to look into it.

http://forum.xda-developers.com/showthread.php?t=704560

[Guest Arr Too]

Is there a better way of disassembling ARM ELF binaries than the objdump from devkitARM_r32-win32? I've tried that on something in /system/bin and it didn't look like it had worked properly at all -- for example, the "-dR" options should make it use the dynamic relocations to annotate the disassembly, but it didn't... and it ended short (seemingly) with "...". :(

Edited December 31, 2010 by Arr Too

[Guest rjm2k]

Is there a better way of disassembling ARM ELF binaries than the objdump from devkitARM_r32-win32? I've tried that on something in /system/bin and it didn't look like it had worked properly at all -- for example, the "-dR" options should make it use the dynamic relocations to annotate the disassembly, but it didn't... and it ended short (seemingly) with "...". :(

no idea sorry, though I did spot something the other day which was using gdb to dissassemble the kernel

[Guest isambard]

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

nice find.

[Guest isambard]

Is there a better way of disassembling ARM ELF binaries than the objdump from devkitARM_r32-win32? I've tried that on something in /system/bin and it didn't look like it had worked properly at all -- for example, the "-dR" options should make it use the dynamic relocations to annotate the disassembly, but it didn't... and it ended short (seemingly) with "...". :(

the best disassembler in the world:

http://www.hex-rays.com/idapro/gallery/arm_linux_elf.htm

if only they'd get off their backsides and write a dalvic processor module...

Edited December 31, 2010 by isambard