Related
What I need...
Someone to repackage a boot.img for me. Specifically, I need a boot.img unpacked, replace the file "/init.inc.rc" with my version, and repack it. (I'm stuck on all Windows, and cygwin is not an option.)
Purpose/Goal
Fix the annoying fact that /emmc is not accessible to almost all market apps, without resorting to using the modified media scanner from CyanogenMod or anything else drastic.
Do not change fstab. /mnt/emmc and /mnt/sdcard will not change.
NOTE: I am not trying to create a symlink on the FAT32 of the SD card.
My idea
Modify /init.inc.rc to change the EMMC settings. (Changes made, need someone with tools. See above.)
Modify /system/etc/vold.fstab to relocate EMMC mount point.
Directory structure
/sdcard (unchanged)
/sdcard/emmc (new location of emmc)
/emmc (Retarget the symbolic link to new location.)
/mnt/emmc (Change to symlink for compatibility, just in case.)
What I want to know...
This arrangement makes /emmc redundant. Can it be safely removed?
When you connect to a PC, how/what does Android map to USB drives? (I assume it is the mount blocks, not the symlinks.)
What odd behaviors may occur? (e.g. will "Settings->SD & phone storage" freak out?)
Maybe, just maybe: How to bottle this into a flashable .zip? (I'll worry about that later.)
If anyone has any pull with the ROM devs (i.e. Koush, rmk40, et al.), I really want to hear from them.
+1. I'd love to make emmc usable in Winamp
Bzzzt... Sorry.
ARGH!
The internal storage is VFAT also. No symlinks allowed.
Blast you, HTC!
What??
I hate doing this, but editing the original post doesn't bump the thread.
I did not want to create a new thread, but what I need has completely changed.
So. BUMP.
Why HTC, WHY?!
Would there be a way to format emmc to NOT be VFAT?
Progress!!!!
I'm close to getting a boot.img ready to test out on my phone.
I spent yesterday hacking away. I've made a Windows tool for handling boot images. I'm about 80% done with the required features. I have all the unpacking finished. I've repacked the ramdisk. I can generate the SHA hash to sign the image. It's just a matter to gluing the last stages together.
ppd0526 said:
Why HTC, WHY?!
Would there be a way to format emmc to NOT be VFAT?
Click to expand...
Click to collapse
I'm sure it could be done, but this is way more work/hassle that I want to deal with. Major obstacle here is that ALL data on emmc is wiped, and I'm not willing to that.
Assuming there are no hidden "features," my approach should be invisible to the Android layer (i.e. will not break any HTC software). HOWEVER... I'm pretty much Senseless, so I'm not too concerned (for my own use) about HTC's apps.
My biggest concern is that the media scanner will generate duplicates of all files found on emmc. But a/the big motivator for this work is to use Winamp, so I don't really give a whoop.
This was tried by koush when we couldn't get cm6 to scan emmc. It didn't work.
Sent from my ADR6300 using XDA App
distINCtINC said:
This was tried by koush when we couldn't get cm6 to scan emmc. It didn't work.
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
What didn't work? Or how did it not work?
I'm not sure. I wasn't involved in the effort. Koush would be the person to talk to but island how to get a hold of him. I just think the OS rejected mounting a physical drive within a physical drive. But don't let that discourage you. It might be still be possible.
Sent from my ADR6300 using XDA App
Any progress on this? I really would love to have /emmc accessible as /sdcard.
Why HTC decided to make /data/data so small and put the rest of the space as /emmc is still a mystery to me. This is my only gripe with this phone.
Progress update
I made my first attempt on Friday, which resulted in a boot loop. So, obviously, I'm missing something important. (Battery pull and recover boot fixed the problem.)
I couldn't work on it this weekend. But I'm going to start digging into it some today.
More info:
It didn't get past the slash screen. Since I'm flashing a boot image, this is obviously where the problem is located. I just don't have any error logging to read over. Since I'm cooking on Windows, I'm wondering if my file permissions and ownership are messed up.
Also, while running my update, I observed that the boot image flashing did not seem to take long at all. So, I'm concerned that I didn't even get a complete flash.
weareallkosh said:
I made my first attempt on Friday, which resulted in a boot loop. So, obviously, I'm missing something important. (Battery pull and recover boot fixed the problem.)
I couldn't work on it this weekend. But I'm going to start digging into it some today.
More info:
It didn't get past the slash screen. Since I'm flashing a boot image, this is obviously where the problem is located. I just don't have any error logging to read over. Since I'm cooking on Windows, I'm wondering if my file permissions and ownership are messed up.
Also, while running my update, I observed that the boot image flashing did not seem to take long at all. So, I'm concerned that I didn't even get a complete flash.
Click to expand...
Click to collapse
That doesn't bode well so far.
just some info
i'm not sure if this will help any of you, but i read before that it said koush tried to get the emmc mounting.. etc... and it didn't work. but - i'm running cm 6.1 stable and winamp can and does read my music found on the internal memory. so it seems to work for me. however - i cannot take picture and have them stored on the internal memory. anyway, good luck.
OK.... I got the ramdisk sorted out. The boot loop is gone. But it doesn't progress past the splash1. sigh.
I need to see the kernel messages, and typically ADB is not available.
drwndphish said:
just some info
i'm not sure if this will help any of you, but i read before that it said koush tried to get the emmc mounting.. etc... and it didn't work. but - i'm running cm 6.1 stable and winamp can and does read my music found on the internal memory. so it seems to work for me. however - i cannot take picture and have them stored on the internal memory. anyway, good luck.
Click to expand...
Click to collapse
CM6 uses a modified media scanner (Android layer) that uses '/mnt' as its base directory, instead of '/mnt/sdcard.' And, as you say, it has its own problems.
I am trying to modify the underlying file system to make hopefully all software work (e.g. HTC stock, Winamp and other media players, 90% of the apps I've played with).
It "works!"
Alright... I have all the tools made, and bugs squashed. So, I can correctly mod a boot image. (Tip: The boot process has a zero warning or error tolerance.)
It fully booted. BUT... A permanent notification "Preparing phone storage.../Checking for errors." did not go away. All emmc directories were absent.
So, I've found a problem. Google didn't return any useful information... Especially annoying is the face that I don't even get a link to the Android source to even get a hint where this notification comes from.
AHA! Fixed that problem. Now, emmc is visible on the sdcard.
NEXT problem (this one I expected):
Media scanner picked up 2 copies of my pictures (I have them on emmc). So, my thought is to start removing links (and references) to emmc in its new location until things clear up.
weareallkosh said:
Alright... I have all the tools made, and bugs squashed. So, I can correctly mod a boot image. (Tip: The boot process has a zero warning or error tolerance.)
It fully booted. BUT... A permanent notification "Preparing phone storage.../Checking for errors." did not go away. All emmc directories were absent.
So, I've found a problem. Google didn't return any useful information... Especially annoying is the face that I don't even get a link to the Android source to even get a hint where this notification comes from.
AHA! Fixed that problem. Now, emmc is visible on the sdcard.
NEXT problem (this one I expected):
Media scanner picked up 2 copies of my pictures (I have them on emmc). So, my thought is to start removing links (and references) to emmc in its new location until things clear up.
Click to expand...
Click to collapse
The double items in media scanner seems like a small issue compared to what it fixes.
More problems created than fixed. (And WHY this is a mess to begin with.)
Postmortem thus far...
Touching ANY code related to where emmc appears will cause Setting to FC if you view the SD & phone storage usage.
Makes media visible to "other" applications, but shows duplicates in HTC's music and gallery apps.
I didn't look too closely at it, but I question that the camera was playing nice with the new config.
ppd0526 said:
The double items in media scanner seems like a small issue compared to what it fixes.
Click to expand...
Click to collapse
SO... I took some time to understand the double items, and why EMMC is such a problem to begin with.
HTC did not modify the media scanner/provider to support EMMC. They modified their APPS. Do a dump of HTC's music and gallery apps. You'll find a LOT of extra code, and a lot of added symbols/strings for handling the phone storage.
In other words, they didn't create a "public" solution. They just made their own private patch, and brushed it under the rug. (How dare we not use THEIR apps???)
Media Scanner/Provider:
I looked at Koush's code changes. I don't understand his changes. I'm not sure how/why it "works." I don't know why it reportedly breaks the HTC apps. I am also not sure that their is a way to mod it to actually fix the issue... Google's code was not written to be extensible. But, I think it may be the way to go in the long run.
What other phones have EMMC? Do they have a fix?
My tools...
There is a lot of code duplication, no GUI, or options. It ain't exactly pretty, but it works.
I'm posting this here for future reference by others wishing to work with boot.img.
Note: This specifically targets 1 file on the ramdisk (init.inc.rc), but with some changes this could do almost anything you would want.
License... Oh. GPL. If you make changes, please send me a patch.
REQUIRES: AutoHotkey (Hey.... it's all I had available, but the code should be easy for anyone to follow and port to another language.)
Runs on Windows (XP). Does not require cygwin. Native GZIP included.
Hi there,
I'm programming something for Windows Mobile 2003. It basically removes and creates files around. One of the files it deletes is special file.reg, which is normally picked up during the hard-reset.
The file gets deleted using "DeleteFile" and very soon after, I force a hard-reset.
The problem is, the special file.reg is deleted from the file system tree, but it is apparently still available from the hard-reset.
I was wondering if there was another function I had to call to "flush" the file system? If not, I need to find a good trick to 1) enforce the file deletion (like rename first, then delete) and to 2) flush current ghost files left around.
The file system on those persistent drives are fat12 and/or fat16.
Thanks in advance for any input,
Simon
The hard reset returns the machine to its first power up state. If 'file.reg' was part of the original build, then the hard reset will restore it from ROM.
Also any programs you have installed to run on startup, will also be lost, so it is going to be a little difficult, if not impossible, to get rid of this file programatically.
Right, but I'm not talking about the ROM.
I'm talking about the persistent memory which are mounted as \Platform and \Application on this device. Those are FAT12 and/or FAT16, and files deleted (normally) do not come back.
In this case, the files are not coming back, they are not hidden either, but the hardreset process is able to pick them up somehow.
I mean, I call it the problem of the "Ghost files", because they are supposed to be nowhere, but they are found during during the hardreset.
(The files are not recreated, they are still not there, but their contents gets loaded. The info in them cannot be placed in ROM as it contains stuff that changes often)
They come back after a hard reset because during cold boot, they're being copied there from the rom or being created by the system. You may be able to delete them afterwards, but the only way to prevent them from being formed will be to re-cook the rom and stop them from being copied/created during boot-up.
The files DO NOT come back, it's gone, I cannot re-delete it. But somehow it is "read" by a program during the hard-reset.
This file is not part of the ROM, it's part of the persistent memory that doesn't get wiped out upon hardreset but is read-write.
I need to wipe out the ghost file that is stuck on the read/write partition... and I need a way to avoid these being created!
I understand that, but clearly the file is being created (or copied from rom) during cold re-boot, otherwise you wouldn't see it coming back. There isn't going to be any easy way to prevent that, unless you can re-cook the rom, or include some sort of user customization that would delete the files prior to using the device. There are lots of ways that the rom could create the files and put them onto persistant storage.
Hi Farmer Ted,
this is not a ROM issue, recooking the ROM will not help. The problem is a FAT12 or FAT16 filesystem that has bogus data in it.
The problem is most likely a bug in the program that reads the persistent folders... It probably reads it in a way that goes around the change made by DeleteFile()...
Changing that program is not possible (in ROM and I don't have the source, it's also necessary). I just need to make sure it can't find the file I've deleted on the persistent directory (not in ROM).
I have done wonderful things to my device thanks in large part to this community. Thank you.
I see that the system partition has about 1 GB of free space yet there are only 427 MB of files in there. Do I need that much free space? If not, how can I safely resize it?
Using parted. I've tried doing it though, shrinking my data partition to give more to system but it won't stick for some reason. Either I'm doing it wrong, or it doesn't work
The parted binary for android can be found on Cyanogenmod's github in the android_bootable_recovery repo
@CNexus, thanks. I appreciate that. I'll take a peek at that. Strangely enough I'm looking to shrink my system partition. I've seen others are wanting the opposite.
I've partitioned PC drives before but this appears to be much more involved.
Does anyone know of an optimum allotment for system and cache that I should follow?
You should be fine whatever you do.
Worst case if something goes wrong, just flash the PIT file for your internal storage size in Odin and all should be good
But yes, this will be more involved since it will need to be all command-line
I figured this out after a struggle, so I figured I would pass along the info in case it helps anyone else.
I'm running CyanogenMod 11 (Android 4.4.4 Kit Kat AOSP based) on my T-Mobile Galaxy S III. I'm on vacation in Mexico, and I had planned to use my Verizon HTC Rezound (aka HTC Vigor) as a phone with a local Mexican SIM card from Telcel. Once I was in Mexico I discovered that the Rezound does not support the GSM/HSPA bands commonly used in North America. It should work fine in Europe, but I could only get Edge service. I decided to try to unlock my T-Mobile Galaxy S III to see if it worked any better.
The free unlock methods I found seemed to require the stock Service Mode applications - so I needed to install a stock rom. I tried to flash a rooted stock 4.3 ROM but the instructions didn't seem to work. The baseband I was running seemed to be too new for the unlock method, which was noted as working with 4.1.1. I tried to downgrade the baseband. It still did not work. I tried flashing a stock rooted 4.1.1 image, and it still did not work. At some point while trying things I realized that no baseband was getting reported in the about screen and no IMEI number was being reported. The phone wasn't even trying to connect to the network. Googling around made me think I hosed my EFS partition. I didn't have a backup.
I hoped that if the EFS partition was corrupted, it might get rebuilt. I used 'dd if=/dev/block/platform/msm_sdcc.1/by-name/efs of=/storage/extSdCard/efs.img' to make a copy of the current state of the efs, then I deleted all the files. I restarted the phone. So data got written to efs, but still I couldn't connect to the network. I didn't have a windows computer with Odin on my trip, by I tried used heimdall with my Mac to write a stock 4.1.1 rom. Still no luck. Not only was the network not working, but the touch screen and buttons were erratic and it would spontaneously reboot. Also, it would generate no sound at all. I figured I practically had a brick. I tossed it in my suitcase and left it until I got home.
When I got home I used ODIN to write the most recent (Android 4.3) root66 stock rooted image. On reboot I got sound back. That was promising. I used dd again to restore the contents of my EFS partition. I was able to connect to the network again. I installed the latest snapshot build of CyanogenMod 11 and everything seems to be working.
I finally put the pieces together. The EFS partition in older roms is formatted with a FAT filesystem, and in new roms it is formatted with an ext4 filesystem. At some point as the phone is upgraded, the EFS partition gets updated to the newer filesystem. Older basebands can not read the data from the ext4 filesystem. If you do not have a backup of the FAT version of your EFS partition, you can't downgrade to the older baseband.
I don't know the precise transition point, but the baseband that comes with 4.3 can read the ext4 partition fine, but the basebands with 4.1 need the FAT partition.
If you open a terminal shell on your phone or with adb shell, then type 'mount', you'll see a list of mounted volumes. The entry for the EFS partition will look like this...
Code:
/dev/block/platform/msm_sdcc.1/by-name/efs /efs ext4 rw,seclabel,nosuid,nodev,noatime,user_xattr,barrier=1,journal_async_commit,data=ordered,noauto_da_alloc,discard 0 0
The first field is the location of the partition. The second field - in this case '/efs' is the mount point. The third field is the filesystem type. Here you see 'ext4'. On your phone, look for the line where the second entry is '/efs'. If the third entry is 'vfat' you can downgrade to older basebands. If it is 'ext4' you can't go to very old basebands unless you have a backup of the old version of your EFS partition and you know how change the filesystem format. Anyone with decent Unix/Linux experience should be able to do that - it isn't hard - but I don't have the old EFS backup to try it out, so I won't try to give any instructions here.
I hope this saves you some trouble.
I think I understand the theory behind what you are trying to explain here, but I dont think this will make a difference.
First though, how did you come to the conclusion that older builds format that partition differently, or more specifically, as vFAT? And that older modems can only read this format?
The reason I dont believe this will make any difference is because much of the data everyone seems to think is located on the EFS partition is not there on the Qualcomm model S3's. For example, the IMEI. On older devices, and maybe some newer ones (dont know for sure), it was moved. If I remember correctly, some of the NV Data is stored on modemst1, some on modemst2, some on param, and some one hidden boot partitions, (and possibly elsewhere). (Dont quote me on those, its been a while since ive looked at all of this so im going by memory and may be slightly off.) But the EFS partition, as best as I can remember, mostly contains data related to DRM, factory mode, carrier info, s/n, and a few other things. I believe there is some important data there related to the modem and network, but not all of it.
The other reason I dont think this would make a difference is I dont see how the system could read and write to other partitions that are vFAT or ext4, but not EFS. It should be able to do so (and is able to do so for the data that is there) regardless of which format it is using. Both formats have been used on this device since day 1.
I am also not certain about the EFS having been re-formatted to a different filesystem at some point. To my knowledge, Odin does not touch that partition, and I've never seen any indication that it has ever formatted anything unexpected in the past. Besides, wouldnt this change its size on disk and thus require the re-formatting of other partitions to compensate? (Im not saying i am right or you are wrong about this, just there are things that aren't making sense to me here.)
I also dont know how comfortable I would be re-formatting ANY partition to a different filesystem. Let alone one that probably cannot be repaired with Odin. For the $5-6 that you might save, it just doesnt seem to be worth the risk to me. (Risk vs reward)
I do apologize if any of this has come off as too argumentative. If your theory does prove to be correct, thats awesome, but I just want to make sure all points are covered before telling anyone something like this is safe to attempt.
Thanks for the post either way though. I do find it interesting!
DocHoliday77 said:
how did you come to the conclusion that older builds format that partition differently, or more specifically, as vFAT? And that older modems can only read this format?
Click to expand...
Click to collapse
I'm trying to retrace my google searches to find the exact reference. It was not a post focused on the SGH-T999, but another similar device. When I find it I'll update to point there.
DocHoliday77 said:
The other reason I dont think this would make a difference is I dont see how the system could read and write to other partitions that are vFAT or ext4, but not EFS. It should be able to do so (and is able to do so for the data that is there) regardless of which format it is using. Both formats have been used on this device since day 1.
Click to expand...
Click to collapse
It is my impression, and please correct me if I am wrong, that the baseband software does not run inside the linux kernel that primarily operates the phone. The low level radio functions have their own system with their own CPU functions and such. There are several reasons this makes sense.
First, interaction with the mobile radio infrastructure is very timing dependent. The software that operates the radios needs to be "real time" - meaning that every task that the system performs must complete in a predictable, determinable amount of time. General purpose, multitasking operating systems like Linux, virtually all Unix systems, and Windows don't do this well. If a general purpose system has specific subsystems that require real time operation, the common solution is put those operations onto a small purpose built hardware with its own processor and software. Even in your standard PC, the ethernet adapters and disk drives have their own processors and firmware.
Second, if the interaction with the radio network was happening in-kernel, then the GPL would require that the software to run this would be open source. The source code for the baseband is not freely available. That suggests that the baseband is separate. It is possible that the code to run the radios could be in a userland process, not in-kernel, and so sidestep the GPL issue. That is unlikely, however, since it would make the timing issues even more difficult.
So if the baseband is software running on a separate CPU, it doesn't matter that the kernel has the modules to read both vfat and ext4. The baseband would need the modules to read that. If certain baseband revisions did not include the modules to read ext4, then the baseband process could not read that data.
DocHoliday77 said:
I am also not certain about the EFS having been re-formatted to a different filesystem at some point. To my knowledge, Odin does not touch that partition, and I've never seen any indication that it has ever formatted anything unexpected in the past. Besides, wouldnt this change its size on disk and thus require the re-formatting of other partitions to compensate? (Im not saying i am right or you are wrong about this, just there are things that aren't making sense to me here.)
Click to expand...
Click to collapse
Other partitions would need to be changed if the size of the EFS partition was increased, but if the size of the EFS partition was not increases, the format could be changed. That process doesn't have to happen in Odin. It could be done at first boot with a particular software revision. The system would need to backup the data on the EFS partition that needs to be saved, reformat the partition using the equivalent of the mkfs command, adjust the partition table and/or the fstab so that the system could mount it properly, remount it, and write back the EFS data - possibly in a new format. All this could be done by any process that had root privs on the system. The baseband could do this itself, even, before the Linux kernel was loaded.
DocHoliday77 said:
I also dont know how comfortable I would be re-formatting ANY partition to a different filesystem. Let alone one that probably cannot be repaired with Odin. For the $5-6 that you might save, it just doesnt seem to be worth the risk to me. (Risk vs reward) ...t I just want to make sure all points are covered before telling anyone something like this is safe to attempt.
Click to expand...
Click to collapse
I definitely don't suggest that anyone tries this unless they are really really really comfortable with this kind of hacking.
BTW - some additional reading in a different T999 thread mentioned that once you go to the NC2 baseband-firmware it is not possible to go back. Makes me think that NC2 is the dividing line if I'm correct about this.
Afaik, you are correct on how the modem operates independently from the rest of the system. That was a good point I didn't take into account, so I will agree that what you stated about the filesystem format being changed is possible. In helping people around here I do periodically run into folks who have never updated beyond 4.1.1 or 4.1.2, so ill try to remember to ask them to check what format the efs partition uses next time. That would probably be the best way to confirm whether or not it was changed somewhere along the way.
As for the sizing of the partition, I do see what you are saying. I was thinking in terms of keeping the usable space the same, which if I am not mistaken would require more space on disk for vFAT.
One other reason I dont think it was changed btw, is I have compared the partition tables of older vs newer builds in the past. It has been a while though, and I wasn't focusing on the efs at the time so I may have overlooked something, but I didnt notice anything different. I was doing this while helping with our debricking process, so it is possible I just didnt see the change, but I kind of feel like I would have had it been there. But, as I just said, it is possible I overlooked it since I wasnt specifically looking for that kind of change.
The inability to downgrade firmware began with our first 4.3 update (MJC). This was done to help prevent tampering and attempts to break into the Knox secure containers.
Something else that just came to mind, is that while you cannot use an older baseband for that reason (Knox), you can use the 4.3 baseband on pre-knox builds (4.1.2 and earlier). So if you were running 4.1.1, for example, you could use the 4.3 baseband. So if your theory is correct wouldnt it mean the 4.3 baseband is capable of reading both formats? And if that is the case, it would mean its something different blocking the SIM unlock in the menu, right?
We do not have 4.4.2 yet, but I have been very active in AT&T's forums lately and can say it is almost the same. You still cannot use older modems as they just wont function, but you can use the 4.4.2 modem on a 4.1.2 or earlier build. The difference, is that while trying the 4.3 baseband on 4.4.2 firmware just doesnt work, if you put a 4.4.2 modem on 4.3 firmware you get an irrecoverable hard brick. Not even jtag will fix it. (right now the only fix is to replace the motherboard). I know that last bit doesn't have much bearing on the topic at hand, but thought I'd throw it in there since on the subject.
So anyway, if the newer basebands will function on older firmware, and the formatting of the efs had been changed, that means the new modems are capable of reading both formats. If all of that is true, the changing from vFAT to ext4 really wouldn't make a difference.
I hope I explained all of that well enough!
Hello everybody, I saw a topic that (installing PIT files) the device partitions were increased .. Does anyone know how to do that for our Galaxy Fame?
[MOD][GUIDE]Partition your internal memory for better App management (Pit Files)
http://forum.xda-developers.com/showthread.php?t=2538947
@Laelson maybe a very late reaction but you can edit pit files with a program, you can find it on google since it's also a program from a xda thread.
But. I suggest all of you guys to NOT do this since editing pit files is Highly risky cause when the pit file get's corrupt and you flash it to your own phone then you will end up with a Brick or a pile of replacement parts.
Also if you modify for example the system partition to be smaller and you will flash later back to stock and if the rom will not fit then you will have problems. Just don't do it, not worth the risk.
The best thing that I can suggest is to get a good Microsd card since the fame doesn't support OTG? Or does it?
Btw, sorry for bumping this.