Develop Bugs

[Q] BML vs MTD (Pros and Cons)

I tried searching for an answer to this question on Google but I haven't been able to find an exact answer. At this moment, I'd like to ask the folks at XDA Community to see what the actual differences are. Listing out Pros and Cons would be much appreciated.
Thank you in advance!!

I hope this helps
I think if you visit this thread you'll get a good understanding, please remember to thank AproSamurai for taking the time to put it together.
http://forum.xda-developers.com/showthread.php?t=1387334

Question Answered
Thanks!
So, I have gathered the following source from the link provided above.
What is a partition?
A partition is an area of allocated space, a division of the whole overall area of space. In this case our partitions on the Epic 4G are /System, /Data, as well as /Cache. All with set permanent sizes.
What is a partition map?
A partition map is the configuration of our partitions, it's what in a vagueness sets our required sizes for the divisions of our nand also known as flash memory. A partition or partition map should not be confused with a file system. An example would be BML and MTD.
What is a file system?
A file system resides on the partition map and governs the data being read/wrote/moved/etc by the Operating System, in this case Android. Changing a file system is less complex than an overall change in partition mapping. They again, are not the same thing.
What is MTD?
MTD is an Open Source Partition map. It allows those who are using it control over how their partitions are sized and how much space is allocated here and how much space is taken away from there. Currently on MTD we have 689 megabytes of space allocated to our /data partition allowing more to be downloaded from the market as an example. MTD as a partition config has YAFFS2 as a file system residing on it governing how data is transferred and the speed of which it is done. EXT2 through 4 aren't possible on the MTD platform, just as YAFFS2 may not be possible on the BML proprietary platform.
What is BML?
BML like MTD is a partition map, however it is proprietary in nature, Close Source if you will. The size for /System /Data /Cache is set and permanent and makes opening up space more of a task for Developers. Stock the Epic 4G comes on BML, and is running RFS as it's file system, once rooted you can leave RFS for EXT4 (Journaled or Un-Journaled) as long as the kernel you use allows for EXT4. But in the end, changing a file system on BML does not lessen or enhance the control you have over your partitions.
[Source/Credit: AproSamurai]
http://forum.xda-developers.com/showthread.php?t=1387334

It sounds like you've got it now! That's a pretty good writeup too, even if it is basically a repost.

Goodroid said:
Thanks!
Click to expand...
Click to collapse
You're welcome

TWRP 2.2.1.1 Backup help

I move old backups to computer then do a new backup.
Sent from my MB855 using xda premium

I'm only guessing but it may be possible that TWRP will only allow so much data to be stored in the TWRP folder. How much do you have stored there? Have you tried getting rid of some old backups?

Boot into TWRP, run the following commands...
adb shell parted /dev/block/mmcblk0 print
adb shell du -s /sdcard
The first will output the partition table details.
The second will tell you how much storage space you are using in the /sdcard partition.

I looked into this a bit in the past but never found clear info. First, as you are aware FFF Extended does some moving around of the partitions to load/unload your primary or alternate ROMs depending on what you are booting into. Root Explorer would give you partition information from within the partitions after FFF Extended has loaded the partition tables as needed for whichever ROM you are loading. TWRP isn't running from "within" one of your two ROMs and therefore it is likely that it does not see your partition tables the same as one or both of your ROMs would. Not much help I know, but I have read through most of the info on the FFF Extended wiki and the documentation isn't real clear on how it manipulates the /sdcard and partition tables as needed to dual boot.

danscxda said:
I looked into this a bit in the past but never found clear info. First, as you are aware FFF Extended does some moving around of the partitions to load/unload your primary or alternate ROMs depending on what you are booting into. Root Explorer would give you partition information from within the partitions after FFF Extended has loaded the partition tables as needed for whichever ROM you are loading. TWRP isn't running from "within" one of your two ROMs and therefore it is likely that it does not see your partition tables the same as one or both of your ROMs would. Not much help I know, but I have read through most of the info on the FFF Extended wiki and the documentation isn't real clear on how it manipulates the /sdcard and partition tables as needed to dual boot.
Click to expand...
Click to collapse
I think you might be a little confused about how FFFe works. The partition table is not a dynamic structure manipulated on the fly by whatever operating system loads at the time. The partition table is stored at a specific location on the storage space, so the device can determine how the storage space has been divided (partitioned). There's only one partition table and it can only be seen one way.
For Android ROMs, you typically need 4 different partition spaces for them to run... boot, system, userdata and cache. FFFe shrinks the media partition (typically called the /sdcard) by approximately 2 GB, then creates another set of these partitions... boot2, system2, userdata2, and cache2, in that space. An alt-ROM has to be specially modified to get the recovery to flash it into this alternate space and to get the booting system to mount the alternate partitions (system2, userdata2, and cache2) instead of the "normal" partitions (system, userdata, and cache). Once all of these have been set up correctly, you just need to have the bootloader select the desired boot partition (boot or boot2) and off it goes.
Hope that clears things up.

[Q] More Data Space - PIT File

Currently running JellyVerse 3.0
Tired of getting Insufficient Storage Space message on my E4GT.
Data mount has approx. 2GB. Seems to be what every PIT file around allocates out of the 16GB internal mmc.
Have been reading up on PIT Magic with goal of making at least a 5GB Data partition on the internal mmc -- want more space for Data/App/Dalvik and less for my photos and mp3 files.
Can anyone give step-by-step how to build a new PIT with PIT Magic?
I assume if I had a different PIT, I could either use a TAR or ZIP rooted ROM or JellyVerse Custom like I am now and use either Heimdall or Odin to repartition with the new PIT and flash each of the pieces of whosever ROM I'm using -- if you want to go step by step on grabbing the right things out of the ZIP, TAR, or OneClick, that would really be nice, but I can probably fumble my way through it -- I'm not a N00B but others might risk having problems if we don't get a good 'how-to' in answer. I've seen lots of questions on this, little real help or instructions.
Here is what I tried first:
Tried to avoid doing this the hard way and so I experimented with Link2SD with a 4GB ext2 or FAT32 partition on my 32GB external card (tried twice). Was able to run Link2SD, find partition, and start linking apps (experimented with Angry Birds), but device would never boot after linking apps. Booted after first running Link2SD and building scripts, but not after apps existed in the linked partition. Would hang at splash screen unless external sd was ejected, then would boot, could reinsert external sd, but Link2SD had missed its' chance to mount and so could never get Link2SD to work as intended. Also, even moving (linking) app, dalvik, and supposedly data, Link2SD didn't really seem to delete the data portion off of the internal mmc so I never really recovered much space.
So I started reading up on PIT files and what's bothering me is this:
The existing PIT (downloaded from device with Heimdall off my Jellyverse install and which matches the "Epic 4G Touch PIT" that is floating around out there shows the following for the Data partition:
Entry 11
Block Size 1,802,240 KB
Block Count 4,194,304 KB
Overall the information in the PIT doesn't make a lot of sense. I'm a bit confused by the nomenclature -- if you scroll through PIT magic, each new entry's Block Size is basically the ending sector of the prior stuff (with a few weird exceptions that I assume have to do with sector alignment). What the author is calling 'Count' is, in theory, the size of the mount, but nothing adds up with what is really going on in the device.
I'm comparting to what busybox df -h says. It shows that there is a 16GB internal memory (that matches Sprint's specs). And the major partitions are as follows (I'm showing the comparison between what unix says and what the PIT file should have created prior to restoring the device image.
Partition df PIT
System 528M 1048M
Cache 309M 614M
Efs 20M 41M
Preload 322M 638M (hidden)
Data 2113M 4194M
Sdcard0 12353M 24133M
Total 15647M 30118M
This totals 15,647 MB and I've read that df uses 1024*1024*1024 for bytes (MiB) whereas flash manufacturers use 1000*1000*1000 so this is basically just a bit shy of the 16,000 that should be in the device, but I'm missing the modem and secondary boot loaders that are small and take up the remaining 400M.
In other words, the device makes sense and I trust what the unix command df is telling me.
But none of this matches the PIT.
I don't want to brick my device with a messed up PIT. It seems like the 'preload' is missing from the PIT (it wasn't in the original Gingerbread ROM).

Swap on empty partitions?

I have noticed a few partitions which are rather empty and doesn't get used up frequently. For example, the /cache partition and the /dev partition.
Not entirely sure whether the phone would use up those partitions as it seems empty majority of the time. So is it possible to create something which inserts a swap file into those partitions and act as a reserve ram?
Not entirely sure whether a huge amount of reads and writes on those partitions would somehow damage the eMMC chip.

[Q] Inc as a data media device

I know I'm late to the party and this was probably already discussed, but I couldn't find it with search. Has anyone considered converting the inc to a data media device (http://www.xda-developers.com/android/what-is-a-data-media-device/)? I've seen this done with other devices (e.g. hp touchpad). I'd be nice to be able to use the EMMC partition for storage and data. I know there is ext4all but I still seem to run out of space quickly since dalvik-cache is half of /data.

Not sure if hboot will let you combine partitions to do what you want; however, lvm can probably accomplish what you're hoping to achieve but it takes quite a bit of effort to setup.
Sent from my One using Tapatalk

I wasn't necessarily thinking we need to combine any partitions. Just don't mount the existing /data and /data/data partitions, and mount the EMMC partition as /data with an emulated sdcard at /data/media. I think this is how the Samsung phones work; you have both "internal" and "external" sdcards. Seems like it should just be some config changes and maybe a recovery that is datamedia aware so you don't erase the emulated sdcard when wiping data.

Smells like a project. I'll see if I will get around to this but this sounds doable.
No promises but my Inc could get bricked and I wouldn't cry over it so I can take a few risks.
Sent from my One using Tapatalk

I've only done a little research so far, but it seems like you'd only need to change a few configuration files. I don't think you could truly brick your Inc, could you? I'm tempted to try and get it working myself but I can't risk bricking my dd.
Sent from my ADR6300 using Tapatalk

ive got 2 incs so I dont mind messing with it, I have a touchpad tho and from what I know (I am decent friends with invisiblek and he does work on the touchpad) the only real difference, is re-partitioning your internal and setting the device tree to mount data as data/media instead of for say /data or /data/data

I have a TouchPad too. Finally made the leap to kk and datamedia there which is what got me thinking about the Inc. The repartioning done for the TouchPad was too make the data partition larger since it now holds both apps and sdcard data. We shouldn't have to do that for the Inc since we already have a partition with 6.6 gig available. Nothing is mounted at /data/media, it's just another directory on the main /data partition. That's why you need a special recovery that "wipes" data instead of formatting...
I've been looking at the changes milaq made. I assume invisiblek did something similar if not the same.
Sent from my ADR6300 using Tapatalk

natediggity said:
I have a TouchPad too. Finally made the leap to kk and datamedia there which is what got me thinking about the Inc. The repartioning done for the TouchPad was too make the data partition larger since it now holds both apps and sdcard data. We shouldn't have to do that for the Inc since we already have a partition with 6.6 gig available. Nothing is mounted at /data/media, it's just another directory on the main /data partition. That's why you need a special recovery that "wipes" data instead of formatting...
I've been looking at the changes milaq made. I assume invisiblek did something similar if not the same.
Sent from my ADR6300 using Tapatalk
Click to expand...
Click to collapse
A fancy flashable script to convert your boot.img to use /data/media should be possible. So far I told it to switch to mmcblk03 from 01 for /data so it's 6.6GB. The other part is relocating fuse to use /data/media for the internal storage instead of /emmc. That should be somewhat easy to change but a bit harder to script.
/data/media was designed for devices that don't have an sdcard slot which the Inc does have so this is more of a proof of concept idea for me than actual utility.
Ok, the last part is recovery and the current recovery images appear to be large enough to make the recovery build part fail. I'm not sure the actual recovery partition size on the inc but the images come to be about 4.5 MB and fail.

zachf714 said:
ive got 2 incs so I dont mind messing with it, I have a touchpad tho and from what I know (I am decent friends with invisiblek and he does work on the touchpad) the only real difference, is re-partitioning your internal and setting the device tree to mount data as data/media instead of for say /data or /data/data
Click to expand...
Click to collapse
/data/media uses fuse on an existing ext4 partition so the recovery as nate said has to be told to wipe /data instead of format (in other words, using an rm command and excluding /data/media).
This makes filesystem corruption harder to fix since the partition can't be wiped from recovery normally unless it's a format which TWRP does have an option to format /data.

tiny4579 said:
A fancy flashable script to convert your boot.img to use /data/media should be possible. So far I told it to switch to mmcblk03 from 01 for /data so it's 6.6GB. The other part is relocating fuse to use /data/media for the internal storage instead of /emmc. That should be somewhat easy to change but a bit harder to script.
/data/media was designed for devices that don't have an sdcard slot which the Inc does have so this is more of a proof of concept idea for me than actual utility.
Ok, the last part is recovery and the current recovery images appear to be large enough to make the recovery build part fail. I'm not sure the actual recovery partition size on the inc but the images come to be about 4.5 MB and fail.
Click to expand...
Click to collapse
Check my device tree, I have a commit on omni that compresses recovery a bit more and I use it to build
Sent from my SCH-I535 using Tapatalk

tiny4579 said:
A fancy flashable script to convert your boot.img to use /data/media should be possible. So far I told it to switch to mmcblk03 from 01 for /data so it's 6.6GB. The other part is relocating fuse to use /data/media for the internal storage instead of /emmc. That should be somewhat easy to change but a bit harder to script.
Click to expand...
Click to collapse
I don't need a flashable script unless it's required. Personally, I'm fine just building a new system image and flashing that.
tiny4579 said:
/data/media was designed for devices that don't have an sdcard slot which the Inc does have so this is more of a proof of concept idea for me than actual utility.
Click to expand...
Click to collapse
datamedia can be used in conjunction with sdcards. This is what the new samsung phones do. I thought the HTC One did as well, but I just remembered it doesn't have a sdcard slot. If you haven't already, check out this page: https://source.android.com/devices/tech/storage/config-example.html. Our config would be similar to the Xoom's.