Jump to content

Partition layout change


Guest rjm2k

Recommended Posts

I think he meant to move /cache to /data!

But that's not possible, the two partitions aren't next to each other, and you can't move the boot partition (/cache is before boot, so you can't resize), as you would need a new boot base address...

I'm actually fairly sure you can move everything with the same method.

What is the best approach for cache? I know users have had problems with it filling up, but I thought most roms use /data for cache to avoid that problem. So is it better for increase cache, or reduce it to 5-10MB and move the additional space into userdata?

PS. The base address is not related to where the boot image is stored in the nand, it is related to where it is loaded into memory, and where it should execute from at boot. The bootloader should find and load the image based on the partition table.

Edited by Tom G
Link to comment
Share on other sites

I think he meant to move /cache to /data!

But that's not possible, the two partitions aren't next to each other, and you can't move the boot partition (/cache is before boot, so you can't resize), as you would need a new boot base address...

I just noticed they are actually next to each other. Cache is mtd4, system is mtd5 and data is mtd6. Cache should be easy to change.

Link to comment
Share on other sites

Guest StevenHarperUK
I just noticed they are actually next to each other. Cache is mtd4, system is mtd5 and data is mtd6. Cache should be easy to change.

This change will make it even more incompatible with other roms (Roms that don;t put the cache in /data).

We need to make a selection of updates - so that people are not stuck with the Hungarian TPT option.

otherwise :unsure: Good work TOM

Link to comment
Share on other sites

Guest IronDoc
I just noticed they are actually next to each other. Cache is mtd4, system is mtd5 and data is mtd6. Cache should be easy to change.

My understanding was that that would change where system begins (is this not the base address) which would require a different kernel.

Link to comment
Share on other sites

Guest jt_mcg

Possibly completely off topic, (and above my knowledge) but wasn't the problem with the Japanese kernel not working that it began from a different base address and had different partitioning.

If it's possible to change those would it be at all possible to use the japanese release kernel?

edited to add link

Edited by jt_mcg
Link to comment
Share on other sites

My understanding was that that would change where system begins (is this not the base address) which would require a different kernel.

The base address is a memory address (RAM) where the kernel begins executing from. It has nothing to do with the nand storage. The bootloader loads the boot image to the base address, but it should locate the boot image via the partition table defined in appsboot.mbn, so it should be possible to move all of the partitions and still have it boot.

The system partition is mounted long after linux boots and is mounted based on the partition table information passed to the kernel. System, userdata and cache are all the same type of partition (yaffs) and mounted in the same way, so if moving the start of userdata works then moving the others should be the same. Moving boot and recovery may not work (though I suspect it would), but there really isn't any point changing them, they are already out of the way at the start of the nand and should be big enough for any future requirements. If we ever do run out of space on boot we can move bits of the kernel into modules to reduce the size.

Adding more partitions would depend on space available in the partition table, but I think there was enough space for another 1 or 2.

Link to comment
Share on other sites

Guest kallt_kaffe

Finally got some time to test this. Made an image folder with isambards 128Mb system partition size and removed all .img files except boot.img and recovery.img. I then replaced both boot.img and recovery.img with clockwork.

So basicly, it repartitions and reboots into recovery ready to flash a ROM. The boot.img recovery will be overwritten once a ROM is installed and but clockwork stays in recovery for future needs.

IMHO all we need now is just create a bunch of predefined packages with different setups. Perhaps it would be nice to also add an empty system.img and an empty userdata.img to make sure the paritions are freshly "formatted" after partitioning.

EDIT:

Here's examples:

128Mb System: http://www.mediafire.com/?a0vaj9j6ca5ci3o

Original partition sizes: http://www.mediafire.com/?xtckadj09b7sxt2

Contains empty images for system and userdata and both boot and recovery are clockwork (Seb's version with EXT3). Does not change the splash.

EDIT2:

I like this... Trimmed down the Jellyfish and currently have 8.2Mb headroom with 128Mb system. Uploading a test build right now. Once again, great work guys.

# df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 208.3M 12.0K 208.3M 0% /dev
/dev/block/mtdblock5 128.0M 119.8M 8.2M 94% /system
/dev/block/mtdblock6 287.6M 41.0M 246.7M 14% /data[/code]

EDIT3: Prelease of JJ RLS4 (lite) that fits well within a 128Mb system partition: http://www.mediafire.com/?t3m427ns34xbw54

Edited by kallt_kaffe
Link to comment
Share on other sites

Guest rickywyatt
I'm actually fairly sure you can move everything with the same method.

What is the best approach for cache? I know users have had problems with it filling up, but I thought most roms use /data for cache to avoid that problem. So is it better for increase cache, or reduce it to 5-10MB and move the additional space into userdata?

PS. The base address is not related to where the boot image is stored in the nand, it is related to where it is loaded into memory, and where it should execute from at boot. The bootloader should find and load the image based on the partition table.

this is what my zte racer partition table looks like

df

/dev: 82532K total, 12K used, 82520K available (block size 4096)

/system: 153600K total, 141016K used, 12584K available (block size 4096)

/data: 302976K total, 40064K used, 262912K available (block size 4096)

/persist: 1536K total, 1156K used, 380K available (block size 4096)

/sqlite_stmt_journals: 4096K total, 0K used, 4096K available (block size 4096)

/cache: 12800K total, 1160K used, 11640K available (block size 4096)

/system/sd: 937297K total, 16453K used, 920844K available (block size 1024)

/sdcard: 6748508K total, 412272K used, 6336236K available (block size 4096)

cant we have some thing like this?

heres the blade

df

/dev: 207176K total, 12K used, 207164K available (block size 4096)

/system: 212480K total, 150440K used, 62040K available (block size 4096)

/data: 213120K total, 58728K used, 154392K available (block size 4096)

/persist: 1536K total, 1156K used, 380K available (block size 4096)

/sqlite_stmt_journals: 4096K total, 0K used, 4096K available (block size 4096)

/mnt/asec: 207176K total, 0K used, 207176K available (block size 4096)

/cache: 42240K total, 1160K used, 41080K available (block size 4096)

/mnt/sdcard: 5962932K total, 2505804K used, 3457128K available (block size 4096)

/mnt/secure/asec: 5962932K total, 2505804K used, 3457128K available (block size 4096

Edited by rickywyatt
Link to comment
Share on other sites

This sounds like something someone could hack a simple tool together for, point it at the hungarian zip folder, adjust the partition sizes (maybe only allow cache, data and system to be altered), hit go, AMSS.MBN and partition_zte are amended and away you go.

Edited by rjm2k
Link to comment
Share on other sites

Guest kallt_kaffe
This sounds like something someone could hack a simple tool together for, point it at the hungarian zip folder, adjust the partition sizes (maybe only allow cache, data and system to be altered), hit go, AMSS.MBN and partition_zte are amended and away you go.

Actually it's appsboot.mbn and partition_zte.mbn, but yes a tool wouldn't be hard to write (for someone who have GUI programming skills which I lack). Actually the tool could contain all the needed files and write the entire "image" folder with the push of a button.

A slider for system and one for cache and userdata gets the rest.

Edited by kallt_kaffe
Link to comment
Share on other sites

The base address is a memory address (RAM) where the kernel begins executing from. It has nothing to do with the nand storage. The bootloader loads the boot image to the base address, but it should locate the boot image via the partition table defined in appsboot.mbn, so it should be possible to move all of the partitions and still have it boot.

The system partition is mounted long after linux boots and is mounted based on the partition table information passed to the kernel. System, userdata and cache are all the same type of partition (yaffs) and mounted in the same way, so if moving the start of userdata works then moving the others should be the same. Moving boot and recovery may not work (though I suspect it would), but there really isn't any point changing them, they are already out of the way at the start of the nand and should be big enough for any future requirements. If we ever do run out of space on boot we can move bits of the kernel into modules to reduce the size.

Adding more partitions would depend on space available in the partition table, but I think there was enough space for another 1 or 2.

That seems to make much more sense. It'd be stupid to have the nand location of the kernel hard coded.

So, is anybody going to try removing the cache partition (or making it very small) & adding the extra space to userdata? It should give us another 40mb to play with.

I'm currently running a stripped down version of modaco froyo alpha 3 on a 128mb system partition, with 16mb free. You can save a fair bit of space on system by removing any apps which could be downloaded from the market, google maps is a pretty big one. Google Talk doesn't appear to be listed in the market, but I think all the other google apps (except talk & market) can go.

Link to comment
Share on other sites

Guest ergo911
You can save a fair bit of space on system by removing any apps which could be downloaded from the market, google maps is a pretty big one. Google Talk doesn't appear to be listed in the market, but I think all the other google apps (except talk & market) can go.

This is a good idea and rom developers should do small basic roms without google apps and someone should release google app pack with newest ones.

And if i install a rom then i choose google apps from the pack and install what i need.

Link to comment
Share on other sites

Guest bebop68

Ok- I've been reading this thread. I know what it means to resize a partition. I think with this you also have to change the boot files to know where the partitions have gone to, yes?

What I'm wondering is - why would you do this?

Is it to make more space for apps on the internal memory?

Thanks

Link to comment
Share on other sites

Guest kallt_kaffe
Ok- I've been reading this thread. I know what it means to resize a partition. I think with this you also have to change the boot files to know where the partitions have gone to, yes?

No, the kernel reads gets the new partition size automaticly. So ROMs does not need to be changed in any way to work on modified partitions sizes (as long as they fit).

What I'm wondering is - why would you do this?

Is it to make more space for apps on the internal memory?

If /system has unused space it will not be used. It's better to have the unused space on /data where all the apps you install are stored.

Link to comment
Share on other sites

Guest StevenHarperUK
So basicly, it repartitions and reboots into recovery ready to flash a ROM. The boot.img recovery will be overwritten once a ROM is installed and but clockwork stays in recovery for future needs.

IMH

Contains empty images for system and userdata and both boot and recovery are clockwork (Seb's version with EXT3). Does not change the splash.

This seems like a great way to go.

After installing:

ROM's would have to have a boot.img in their ZIP so that clockwork didn't get stuck as their boot and recovery :unsure:

Obviously you can do Total Phone Transplants (like Volcano does), by simply replacing system.img and boot.img.

One Question.

If you put a recovery.img - just by itself in the image directory - will the MENU + UP install just the single image?

Link to comment
Share on other sites

Guest fonix232
Actually it's appsboot.mbn and partition_zte.mbn, but yes a tool wouldn't be hard to write (for someone who have GUI programming skills which I lack). Actually the tool could contain all the needed files and write the entire "image" folder with the push of a button.

A slider for system and one for cache and userdata gets the rest.

I *THINK* I may be able to do something in the case, but I only know C#, and I lack the skills of writing to given areas, etc.

Link to comment
Share on other sites

i like the idea of having extra space, is there anyway i can implement this whilst install the japjelly rom, and wud i need to wipe data and everything becuz it would take to long to reinstall all my apps

Link to comment
Share on other sites

Guest samjam
This change will make it even more incompatible with other roms (Roms that don;t put the cache in /data).

We need to make a selection of updates - so that people are not stuck with the Hungarian TPT option.

otherwise :unsure: Good work TOM

Surely it can be fixed with a bind-mount in the init file?

Link to comment
Share on other sites

Guest kallt_kaffe
Surely it can be fixed with a bind-mount in the init file?

Yes, I was thinking along these lines myself today. You make the cache partition 1Mb or so (you propably need to have one to make sure Clockwork doesn't go mayhem when it tries to wipe it.

Then instead of mounting the cache in init.rc we would just do some linking magic to make /cache point to, for example /data/relocated_cache

Link to comment
Share on other sites

Guest Krinyo
Yes, I was thinking along these lines myself today. You make the cache partition 1Mb or so (you propably need to have one to make sure Clockwork doesn't go mayhem when it tries to wipe it.

Then instead of mounting the cache in init.rc we would just do some linking magic to make /cache point to, for example /data/relocated_cache

Good idea! +1

I love the more space on my phone. :unsure:

Link to comment
Share on other sites

Guest oh!dougal

Cross-posted from the Volcano thread ...

It is very important that the phone-software-image downloads without ANY errors.

Hence two recommendations --

-- md5 checksums MUST be posted for all such full-phone-images

and

-- if you don't know how to check an md5, then, really, this is not suitable for you, at this point.

Experienced uploaders will be aware of the need to check that their upload, as published, matches their original!

Link to comment
Share on other sites

Finally got round to this and it worked fine, I used the original hungarian update with Toms resize image over the top, I had done a clockwork backup before so I copied the system.img, boot.img, recovery.img and userdata.img over the image directory too, this way when I installed the flash everything was up and running alread with no need to restore anything.

ps just in case this hasn't been spotted already it seems that oemsbl.mbn is the flasher, it contains the text "update from t-flashcard!" which is what's displayed when you run the update.

Edited by rjm2k
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.