I have successful compiled the exFAT userspace driver from http://code.google.com/p/exfat/ together with libfuse.
So we are theoretically able to mount every exFAT formatted drive (connected via OTG and also the external sdcard, BUT THIS IS NOT YET FULL TESTED).
This howto is far away from being perfect. Also my english isn't perfect - sorry. Feel free to send me corrections.
@Mods: I think it's a development-related thread. If this is not your mind, please move it to the right section - thank you very much (and also for your continuously work in the "background").
* For updates please have a look in the footer of this post, I forgot to reserve a second "post space" *
Please be very careful! I am not responsible for any damage or lost data on your phone or storage. I have tested this on my phone with a connected card reader and with the "external" sdcard
(Galaxy S2, usually mounted at /sdcard/external_sd).
ATTENTION:
I have discovered one "big" problem that must be solved before all other things and I NEED PERHAPS SOME HELP!
Binaries attached read update no. 2:
After every reboot the exFAT partition will be damaged WITHOUT modification of the vold.fstab config, so don't use a card or drive with important data on it.
This has to do with the automount function of the "New Volume Manager Daemon" Vold.
I suspect that the daemon wants to mount the exFAT volume as FAT32 read/write and overwrites the first bytes of the the first block. I will check this.
It doesn't matter if it's the "external" card or a connected drive/sdcard reader.
The problem:
dd if=/dev/block/mmcblk1p1 of=/sdcard/exfat_ok.bin count=1 bs=1024
hexdump -C /sdcard/exfat_ok.bin
the correct hex:
00000000h: EB 76 90 45 58 46 41 54 20 20 20 (three bytes and then the string EXFAT plus three spaces. This is the recognition string for the exfat-utils (exactly 8 bytes)
dd if=/dev/block/mmcblk1p1 of=/sdcard/exfat_not_ok.bin count=1 bs=1024
hexdump -C /sdcard/exfat_not_ok.bin
after a reboot of the phone the string changes to
00000000h: 52 52 61 41 58 46 41 54 20 20 20 (four new bytes at the beginning -> AXFAT, the recognition of the partition fails) I think no more changes are made.
This is not in relation to the exFAT tools or the FUSE library, the "damage" happens before!
Beside that, the exFAT card seems to be usable and after manually mount to /sdcard/external_sd the card can be activated (under settings - memory) - Sorry I have a german GUI...
STOP READING HERE IF YOU DON'T WANT TO PLAY WITH YOUR DATA ON THE EXFAT PARTITION!
There is no long term experience with this. Don't try it if you don't have some skills with Linux and Android. Make a full backup!
You have been warned...
[Q] Why exFAT and not using ext2/3/4 or any other file system?
[A] I don't know. It's your decision. exFAT is developed mainly for flash memory and could be used "out of the box" with newer windows versions and Mac OS X in contrast to ext2/3/4.
Sadly there is no good extX windows driver out available.
exFAT also supports XDHC card from 32 GB upwards. See http://en.wikipedia.org/wiki/ExFAT for more details.
XDHC cards are reported to work with the SG2.
This makes it interesting for micro sdcards greater than 32 GB (if your are lucky and have one) and for large files (greater than 4 GB), like video files.
Note: FAT32 is of course able to address more than 32 GB, but not "official".
There are many disadvantages as well, read the article.
[Q] Is it free and/or free to use?
[A] Once again, I don't know exactly. Tuxera http://www.tuxera.com/ has an agreement (licence program) with Microsoft and announced an exFAT driver for Android, but I couldn't find a free downloadable (source) package.
The driver is probably free to use but not free to distribute and until now not released.
The exFAT project on Google Project Hosting is licensed under GNU GPL v3, so we will and can use it free. But it's still in beta stage.
[Q] What do I need?
[A] A rooted Android phone with a suitable kernel and fuse support, take siyah (because it a good kernel). I have only a Samsung Galaxy S2, that's because the thread is here.
Enough free memory. Installed busybox. Access via adb shell or a ssh-terminal connection (QuickSSHd or SSHDroid from the market).
An other option is to use a terminal window on the phone.
[Q] What could be possible?
[A]
automatically mount the OTG drive with util-linux-ng or vold or something like that (needs support from kernel or ROM)
replace the FAT32 partition of the "external" sdcard (external_sd) with exFAT (needs support from both kernel and ROM I think)
OK, let's start...
First option, the harder way (you need a linux machine for this): Compiling the driver and utils
Download the CodeSourcery Toolchain/Crosscompiler for ARM EABI for Linux from https://sourcery.mentor.com/sgpp/lite/arm/portal/[email protected]=lite (tested with 2011.03-41, I saw a newer untested version Sourcery G++ Lite 2011.03-42)
Install the compiler on your linux box with (for example) sh ./arm-2011.03-41-arm-none-linux-gnueabi.bin, the installer will asking you a few questions, it should be easy.
Download latest stable fuse (fuse-2.8.6.tar.gz) from http://fuse.sourceforge.net/
Download fuse-exfat (exfat-utils-0.9.5.tar.gz and fuse-exfat-0.9.5.tar.gz) from http://code.google.com/p/exfat/ or use my prepared packages with the Makefiles
Prepare the cross compiler, this is my example script, please change the path (CROSS_PATH) to the CodeSourcery binaries and the CROSS_ROOT path
Make a directory (CROSS_ROOT) for the libraries and the headers, ex.:
/android/src/cross/lib
/android/src/cross/include
---- File prepare_codesourcery.sh
#!/bin/bash
export CROSS_PATH=/android/CodeSourcery
export CROSS_ROOT=/android/src/cross
export ARCH=arm
export PATH="$CROSS_PATH:$PATH"
# version 2011.03-41-arm-none-linux-gnueabi
export CROSS_COMPILE="$CROSS_PATH/bin/arm-none-linux-gnueabi-"
export CFLAGS=' -I$CROSS_ROOT/include -g -O2 -static -march=armv6 -mfpu=neon -mfloat-abi=softfp'
export LDFLAGS=' -L$CROSS_PATH/arm-none-linux-gnueabi/libc/lib -L$CROSS_ROOT/lib -Wl,--whole-archive -lpthread -lrt -ldl -Wl,--no-whole-archive'
export CC="$CROSS_PATH/bin/arm-none-linux-gnueabi-gcc"
----
Export the setup:
. ./prepare_codesourcery.sh
Check the path with
arm-none-linux-gnueabi-gcc -v
Compile libfuse
./configure --host=arm-linux --enable-util --enable-lib --disable-mtab --enable-static=yes --enable-shared=no
make
copy the static libraries libfuse.a and libulockmgr.a from fuse-2.8.6/lib/.libs to $CROSS_ROOT/lib
copy the headers (.h-files) from fuse-2.8.6/include to $CROSS_ROOT/include
c) and d) is not really necessary, but is used for the flags to find the headers and libs, see the file prepare_codesourcery.sh above.
Compile fuse-exfat
I had no luck with SCons (a substitution for make) to cross compile for ARM, so I created some Makefiles to build fuse-exfat and exfat-utils, see attachement
Note: the next step is not necessary, libexfat is also included in exfat-utils if you use the attached source package:
Use your downloaded sources package and copy the Makefiles from my packages to every directory or use my source packages
In fuse-exfat/fuse-exfat-0.9.5 run make
Compile exfat-utils
In fuse-exfat/exfat run make
Note: If you get errors like strip: "Unable to recognise the format of the input file" then you have to symlink arm strip to strip temporary with
ln -s $CROSS_PATH/bin/arm-none-linux-gnueabi-strip $CROSS_PATH/bin/strip
so arm-strip is used instead of strip from your linux dist
Second option: Download the binaries
1.-9. Don't care about it...
Copy all binaries to your phone. They are big but "portable" because of the static build. You can use adb or any other method. The files must be executable, so place them for example in /system/xbin or /data/ and chmod them 755
Connect an empty hard drive, empty pen drive or a card reader with an empty sdcard to the phone with an OTG cable. The drive should only contain a prepared partition (don't care about the file system).
But you can also create a partition with fdisk on the phone, if your busybox installation is useable.
Check the connection of the USB devices with
lsusb
or something like that
Check the partitions with
cat /proc/partitions
You have to see a new partition like sdc1. The partition is visible under /dev/block/platform/s3c_otghcd/sdc1
Create a new exFAT partition with
mkexfatfs /dev/block/platform/s3c_otghcd/sdc1
Check the type of partition with
fdisk -l /dev/block/platform/s3c_otghcd/sdc
(you should see it as "HPFS/NTFS")
Make a new directory ex.
mkdir /data/exfat
for the mount point
Mount the new exFAT partition read/write with
mount.exfat-fuse -o rw /dev/block/platform/s3c_otghcd/sdc1 /data/exfat
to mount point /data/exfat or any other path
or for testing with
mount.exfat-fuse -o ro /dev/block/platform/s3c_otghcd/sdc1 /data/exfat
readonly
To unmount the device use
sync
umount /data/exfat
Thanks to gokhanmoral for his great kernel, tolis626 and olifee (members of this forum) to give me the idea of doing this, unknown devs from http://repository.timesys.com/ for a example Makefile to bypass
the unwieldy "SCons". I wasn't able to use it for cross compiling because of tons of parameters and variables, my shame...
Links:
exFAT (GPL): http://code.google.com/p/exfat/wiki/QuckStartGuide (it's not a typo)
Some informations: http://en.wikipedia.org/wiki/ExFAT
SiyahKernel: http://forum.xda-developers.com/showthread.php?t=1263838
exFAT Makefile: http://repository.timesys.com/buildsources/f/fuse-exfat/fuse-exfat-0.9.5/fuse-exfat-0.9.5-make.patch
CodeSourcery: https://sourcery.mentor.com/sgpp/lite/arm/portal/[email protected]=lite
FUSE (Filesystem in Userspace): http://fuse.sourceforge.net/
Update no. 1 | 01/12/2011
I think I made one step forward: It's vold as I can see.
I have commented out the block for the external_sd in /system/etc/vold.fstab
# external sdcard
#{
# ums_path = /sys/devices/platform/usb_mass_storage/lun1/file
# asec = enable
#}
#dev_mount sdcard1 /mnt/sdcard/external_sd auto /devices/platform/s3c-sdhci.2/mmc_host/mmc1
Now after new rebooting the partition is not damaged and I was able to mount it as expected at /sdcard/external_sd.
The disadvantage is now is that the system cannot recognize the card as a regular sdcard and the memory part in settings is greyed out.
It's like the card is not insert for the ROM, nevertheless the directories are shown in a file explorer like "root explorer" (with free/used values and I could edit a text file with a build-in editor)
Update no. 2 | 05/12/2011
I am now sure after some (more) tests, it's the vold daemon.
To mount a exfat volume, the configuration /system/etc/vold.fstab needs modification.
DO NOT MOUNT A VOLUME WITHOUT MODIFICATION
vold (version 2) is locked to VFAT/FAT32 volumes. Earlier versions had support for ext(2/3/4 ???) volumes too, this was removed by Google and/or Samsung (don't know).
Sadly I can't find a documentation for vold2 and I am stuck here. Because for replacing the "external_sd" from FAT32 to exFAT it's also necessary that vold2 recognizes the card correctly. (Because of the "asec" mounts for Apps2SD).
Perhaps it's possible to map this mounts to the internal sdcard (setting asec = enable in vold.fstab), but I haven't tried this yet.
Conclusion: It's possible to mount such exFAT volume with some restrictions and with modification of the vold.fstab.
Specs:
/data/bin/dumpexfat /dev/block/mmcblk1p1
dumpexfat 0.9.5
Volume label
Volume serial number 0xb965fe93
FS version 1.0
Sector size 512
Cluster size 32768
Sectors count 25173456
Free sectors 25169728
Clusters count 393284
Free clusters 393277
First sector 0
FAT first sector 128
FAT sectors count 3136
First cluster sector 3264
Root directory cluster 5
Volume state 0x0000
FATs count 1
Drive number 0x80
Allocated space 0%
Please no questions about the values, there is a second ext4 partition on the card...
So the configuration in vold.fstab and perhaps some other files have to be changed. I have nearly no knowledge with "void". Is a expert out there?
From command line a short speed test shows this result (no other GUI test possible in the moment):
/data/bin/hdparm -tT /dev/block/mmcblk1p1
/dev/block/mmcblk1p1:
Timing cached reads: 228 MB in 2.01 seconds = 113.27 MB/sec
Timing buffered disk reads: 36 MB in 3.02 seconds = 11.92 MB/sec
Card: Patriot 16 GB Class 10, no OC
RESERVED
Reserved...
Did you test the overhead of a FUSE filesystem on Android? As far I know the performance may be sub-optimal because of the overhead of using a filesystem on userspace mode. The Tuxera driver uses kernel mode and is very optimized, but as far I know it's only for OEM's that want to license the module for their devices.
Anyway, very interesting, mainly because exFAT is the default filesystem for SDXC.
z3r0n3 said:
Did you test the overhead of a FUSE filesystem on Android? As far I know the performance may be sub-optimal because of the overhead of using a filesystem on userspace mode. The Tuxera driver uses kernel mode and is very optimized, but as far I know it's only for OEM's that want to license the module for their devices.
Anyway, very interesting, mainly because exFAT is the default filesystem for SDXC.
Click to expand...
Click to collapse
No, I have not tested this. It will be one of the next steps if there is a solution for the problem I wrote about. In the moment I don't know if it's kernel related, rom/vold related or anything other. But I think it should have less overhead than NTFS in userspace, surely more than FAT32. Please read the comments about speed at http://code.google.com/p/exfat/updates/list And yes, the Tuxera driver is not for us "end users". Perhaps Samsung will give us a present in the next official ROM release
z3r0n3 said:
Did you test the overhead of a FUSE filesystem on Android? As far I know the performance may be sub-optimal because of the overhead of using a filesystem on userspace mode. The Tuxera driver uses kernel mode and is very optimized, but as far I know it's only for OEM's that want to license the module for their devices.
Anyway, very interesting, mainly because exFAT is the default filesystem for SDXC.
Click to expand...
Click to collapse
I also did not test it . However, it should be comparable to a desktop machine (taking the slower CPU into account). My NTFS-3G experience for several years has shown it is actually pretty fast, but takes up a lot of CPU time if high fragmentation is present. Nevertheless, I think the throughput (with our devices CPU) will still be much higher than writing to SD-card in most cases.
And yes, although Linus said FUSE-filesystems are just toys, http://www.spinics.net/lists/linux-fsdevel/msg46078.html, they are very fast and stable toys in my experience.
I think we will not see an open-source kernel-module for exFAT / NTFS-3G in the near future. For one, there is the licensing-issue (which will be much more of a problem if it is included in the kernel-sources / can be built against them), and on the other hand, it always took some YEARS time until a new filesystem was reliable enough to warrant an accepted kernel module. After all, btrfs is just becoming widely accepted and stable after 4 years of development (and a shorter time in-kernel). And this is expected to be the next-gen filesystem for linux, and as such the focus of development. With the correct mount-options, it should also be nice to SD-cards . Maybe there will be some time to try it when kernel 3.1 (with the 'stable' version) comes to our phones.
So for the next years, the FUSE-solution is the best we can get, and for Android, the most compatible one across kernels and devices (it only needs a kernel-dependent kernel-module in addition to whats cooking here, after all). The perfomance graphs by Tuxera on their site even show that their fuse-exFAT is faster than in-kernel FAT, so I guess we should not worry about performance even with the open-source beta implementation. Maybe battery life could be an issue if CPU-usage spikes when copying large files, that might be worth some testing.
I'm personally not switching to exFAT in the near future, but will watch this thread and might do some experiments in some weeks when I have more time .
Thanks for the good work, smitna!
olifee said:
I also did not test it . However, it should be comparable to a desktop machine (taking the slower CPU into account). My NTFS-3G experience for several years has shown it is actually pretty fast, but takes up a lot of CPU time if high fragmentation is present. Nevertheless, I think the throughput (with our devices CPU) will still be much higher than writing to SD-card in most cases.
And yes, although Linus said FUSE-filesystems are just toys, http://www.spinics.net/lists/linux-fsdevel/msg46078.html, they are very fast and stable toys in my experience.
I think we will not see an open-source kernel-module for exFAT / NTFS-3G in the near future. For one, there is the licensing-issue (which will be much more of a problem if it is included in the kernel-sources / can be built against them), and on the other hand, it always took some YEARS time until a new filesystem was reliable enough to warrant an accepted kernel module. After all, btrfs is just becoming widely accepted and stable after 4 years of development (and a shorter time in-kernel). And this is expected to be the next-gen filesystem for linux, and as such the focus of development. With the correct mount-options, it should also be nice to SD-cards . Maybe there will be some time to try it when kernel 3.1 (with the 'stable' version) comes to our phones.
So for the next years, the FUSE-solution is the best we can get, and for Android, the most compatible one across kernels and devices (it only needs a kernel-dependent kernel-module in addition to whats cooking here, after all). The perfomance graphs by Tuxera on their site even show that their fuse-exFAT is faster than in-kernel FAT, so I guess we should not worry about performance even with the open-source beta implementation. Maybe battery life could be an issue if CPU-usage spikes when copying large files, that might be worth some testing.
I'm personally not switching to exFAT in the near future, but will watch this thread and might do some experiments in some weeks when I have more time .
Thanks for the good work, smitna!
Click to expand...
Click to collapse
I have some bad experiences with NTFS-3g on my netbook. Trying to transfer a large number of files from my netbook (running Arch Linux) to my external HDD (that is NTFS) and the transfer was slow and my CPU time are always on 100%. That's why I asked if it was tested, because I don't really know if FUSE is suitable for embedded devices. But yeah, the only way to know is to test, and it's still too early for that .
But licensing is really a issue? I know that Linux have module to read a NTFS partition (but not write, this is why we have NTFS-3g) and there was some work for a read-only module for exFAT too (sadly, it didn't get much attention).
Anyway, I'm not switching for exFAT too anyway and I don't know how they aprove exFAT as the default filesystem on SDXC cards, but it's important anyway and will be critical somewhere in the future to have support to this filesystem.
First of all, thanks for your work on this. I was shocked to discover that my SGS2 wouldn't support any filesystems that support large files on external sdcards. I was able to get your solution working in the sense that I could format an sdcard with exfat, mount it, write to it, and unmount it. Awesome! I am having one serious problem though: After editing the vold.fstab and rebooting, I get constant FCs after trying to install any APKs. It doesn't matter if I have my external_sd mounted or not. And these are not apps that are trying to install to the sdcard. Any ideas?
I've got the AT&T version of the SGS2 (i777), but I'm running Siyah's latest kernel. The FCs just say it's the media process.
dildano said:
First of all, thanks for your work on this. I was shocked to discover that my SGS2 wouldn't support any filesystems that support large files on external sdcards. I was able to get your solution working in the sense that I could format an sdcard with exfat, mount it, write to it, and unmount it. Awesome! I am having one serious problem though: After editing the vold.fstab and rebooting, I get constant FCs after trying to install any APKs. It doesn't matter if I have my external_sd mounted or not. And these are not apps that are trying to install to the sdcard. Any ideas?
I've got the AT&T version of the SGS2 (i777), but I'm running Siyah's latest kernel. The FCs just say it's the media process.
Click to expand...
Click to collapse
Sorry for my later answer!
This should be nevertheless a problem with the app2sd service and I have no solution for this. My thread here is only a howto, nothing for the "daily to use"...
I also don't know why there is no other selectable alternative file system for "us users" to use for the external card by default and not FAT32.
The media service depends on the vold daemon to my knowledge. So I cannot recomment this for the default external sdcard, because of the media service scans. If you want to store larger files (e.g. video files), you should better split your sdcard in one FAT32 partition and an additional ext2/3/4 partition. On this partition there is no 4 GB limit. The "media scanner" will not scan the files (videos etc.) on the partition, but you can choose the videos from your favorite player with the file chooser.
Hope this helps you a little bit.
Thanks for the response. I was actually trying out multiple partitions over the weekend to no avail. Granted, I was trying a combination of FAT32 and NTFS. It would actually work for a while until the NTFS partition would appear to get corrupted. I thought about ext2, but my understanding is that Samsung somehow disabled ext* support for external SD cards. Is that not the case? Anyway, I'm surprised that more folks haven't caught onto your work here because storing large files seems to be a fairly common issue for SGS2 users.
dildano said:
Thanks for the response. I was actually trying out multiple partitions over the weekend to no avail. Granted, I was trying a combination of FAT32 and NTFS. It would actually work for a while until the NTFS partition would appear to get corrupted. I thought about ext2, but my understanding is that Samsung somehow disabled ext* support for external SD cards. Is that not the case? Anyway, I'm surprised that more folks haven't caught onto your work here because storing large files seems to be a fairly common issue for SGS2 users.
Click to expand...
Click to collapse
I am using an ext3 partition with deactivated journalling and noatime option on the sdcard since months without problems. Of course I have also a FAT32 partition on the card to stay compatible with vold and media scanner. With a start script it is mounted after every phone restart.
OK, I must have misunderstood. So is it just that vold will not allow us to automatically mount ext* partitions? I'll try it with a script as soon as I can get some time. Thanks.
I would like to try this, for use connecting my camera which has a exfat formatted sdxc card in it via OTG. But have a couple questions since I can't test at this moment.
1: Do the binaries work on a ICS build (Siyah Kernel) or do they need updated?
2: Do I have to make any vold.fstab changes to prevent FS damage when using a OTG cable or is that just external sd?
3: If I have to make the changes will other devices (not memory) work normal without manual interaction?
shadowofdarkness said:
I would like to try this, for use connecting my camera which has a exfat formatted sdxc card in it via OTG. But have a couple questions since I can't test at this moment.
1: Do the binaries work on a ICS build (Siyah Kernel) or do they need updated?
2: Do I have to make any vold.fstab changes to prevent FS damage when using a OTG cable or is that just external sd?
3: If I have to make the changes will other devices (not memory) work normal without manual interaction?
Click to expand...
Click to collapse
Hello, I am still on GB, but I guess it should work on ICS too.
If ICS (or better the vold daemon) has not changed its behavior you have to modify vold.fstab to prevent damages. To do this, you have to disable automounting the exfat OTG device (commenting out the part for OTG and reboot). The other partitions (internal and external memory should work like before). Then mount your camera card manually. But be very careful with your data/pictures!
Hello, I'm working on an HTC Mazaa with Windows Phone and inside a partition I've found several times the EXFAT header, so I'm trying to mount it, but looks like it's EXFAT 2.0, while your implementation covers only 1.0.
Do you know if it's somehow possible to mount EXFAT 2.0? On Windows, on Linux, modifying your tool, whatever!
Here's the header:
Code:
012f7400 eb 76 90 45 58 46 41 54 20 20 20 00 00 00 00 00 |.v.EXFAT .....|
012f7410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f7440 00 00 00 00 00 00 00 00 00 1b 00 00 00 00 00 00 |................|
012f7450 20 00 00 00 36 00 00 00 8c 00 00 00 74 1a 00 00 | ...6.......t...|
012f7460 02 00 00 00 94 01 eb 07 00 02 10 00 09 00 02 80 |................|
012f7470 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
012f7480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f75f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
012f7600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f77f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
012f7800
Thanks!
WhiteTrap said:
Hello, I'm working on an HTC Mazaa with Windows Phone and inside a partition I've found several times the EXFAT header, so I'm trying to mount it, but looks like it's EXFAT 2.0, while your implementation covers only 1.0.
Do you know if it's somehow possible to mount EXFAT 2.0? On Windows, on Linux, modifying your tool, whatever!
Here's the header:
Code:
012f7400 eb 76 90 45 58 46 41 54 20 20 20 00 00 00 00 00 |.v.EXFAT .....|
012f7410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f7440 00 00 00 00 00 00 00 00 00 1b 00 00 00 00 00 00 |................|
012f7450 20 00 00 00 36 00 00 00 8c 00 00 00 74 1a 00 00 | ...6.......t...|
012f7460 02 00 00 00 94 01 eb 07 00 02 10 00 09 00 02 80 |................|
012f7470 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
012f7480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f75f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
012f7600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f77f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
012f7800
Thanks!
Click to expand...
Click to collapse
I don't think that I can give you a good answer, sorry. It's not my tool, it's the exFAT driver from http://code.google.com/p/exfat/, the latest is fuse-exfat-0.9.7.tar.gz and I don't see any notes for a "version 2" in the ChangeLog. Are you really sure about the version? If there is a version 2, I guess it's more than only a change to the header.
I recommend you to post the question in the mailing list https://groups.google.com/group/exfat?hl=en. It is rumored that exFAT works natively on the new S3, but I don't know if this will be true and I have strong doubts that Samsung will release the sources of the driver.
smitna said:
I don't think that I can give you a good answer, sorry. It's not my tool, it's the exFAT driver from http://code.google.com/p/exfat/, the latest is fuse-exfat-0.9.7.tar.gz and I don't see any notes for a "version 2" in the ChangeLog. Are you really sure about the version? If there is a version 2, I guess it's more than only a change to the header.
I recommend you to post the question in the mailing list https://groups.google.com/group/exfat?hl=en. It is rumored that exFAT works natively on the new S3, but I don't know if this will be true and I have strong doubts that Samsung will release the sources of the driver.
Click to expand...
Click to collapse
It's fuse-exfat itself that says the version is 2.0. I'll try on the ML, but looks like there are big differences. If I make fuse-exfat ignore the fact that it's 2.0 it says that there are 2 FAT, which I think non-banal modifications to the implementation.
Thanks!
Seems that exFAT 2.0 is (or is very similar to) TexFAT.
I just wanted to say thanks I just tested this and the binaries works great on ICS 4.0.3 (LPG) using Siyah Kernel.
I plugged in my Panasonic Lumix TS2 digital camera with a 64GB sdxc card and was able to mount it fine on my S II with a OTG cable.
shadowofdarkness said:
I just wanted to say thanks I just tested this and the binaries works great on ICS 4.0.3 (LPG) using Siyah Kernel.
I plugged in my Panasonic Lumix TS2 digital camera with a 64GB sdxc card and was able to mount it fine on my S II with a OTG cable.
Click to expand...
Click to collapse
Fine and thanks for sharing your experience! It's good to hear that the driver is useful for you.
I have galaxy s3 and the 64 gb exfat formatted card works on the stock rom of it.
But when i switch to custom rom which are not based on galaxy s3 own stock rom the card stops working.
No other rom beside galaxy s3's own come with exfat driver. so i was wondering if i use this in custom rom as for now its Cyanogenmod 10, would this mod of yours work?
please let me know.
thanks.
Hallo, I found source code (tocparser) and compiled it and got it a try, but I found more than from what I expected! Tool is abble to dump and write from/to low level things in Xperia phone! Here is tool and simple info about what I tested and what I found.
Warning:
I am not responsible for everything related to using this tool! You can try but on your own risk!!! You can hard brick your device using this tool!!! I tested only "read only mode" and never tried to write to low level memory, so you using this tool on your own risk!
Usage:
Usage:
tocparser [-h] [-dD devicename] [-l] [-gG partition] [-rw partition:filename
or
tocparser -p partition -f filename
-h Print this help.
-d devicename Open device as read-only (default).
-D devicename Open device as read-write.
-l List all partition and image entries.
-g partition Get information for image inside partition.
-G partition Get information for partition.
-r partition:filename Read content of partition into file.
-w partition:filename Write content of file into partition.
-p partition -f filename Write content of file into partition.
By default tocparser will open /dev/block/mmcblk0 as read-only.
If -p and -f are used then /dev/block/mmcblk0 will be opened as read-write.
Click to expand...
Click to collapse
I got dumped some infos:
tocparser -l
Printing TOC at 20000
Offset Size Flags Align LoadAddr ID
0x00000200 0x0000556c 0xffffffff 0xffffffff 0xffffffff "ISSW"
0x00017e00 0x00008150 0xffffffff 0xffffffff 0xffffffff "BKP_PRCMU_1"
0x0000576c 0x00021854 0xffffffff 0xffffffff 0xffffffff "X-LOADER"
0x00046fc0 0x00006408 0xffffffff 0xffffffff 0xffffffff "BKP_MINIT_1"
0x00100000 0x00008150 0xffffffff 0xffffffff 0xffffffff "PWR_MGT"
0x00108150 0x00007eb0 0xffffffff 0xffffffff 0xffffffff "MEM_INIT"
Click to expand...
Click to collapse
Got dumped these partitions to the internal sdcard by using command:
~ # tocparser -r ISSW:/mnt/sdcard/ISSW
tocparser -r ISSW:/mnt/sdcard/ISSW
~ # tocparser -r BKP_PRCMU_1:/mnt/sdcard/BKP_PRCMU_1
tocparser -r BKP_PRCMU_1:/mnt/sdcard/BKP_PRCMU_1
~ # tocparser -r X-LOADER:/mnt/sdcard/X-LOADER
tocparser -r X-LOADER:/mnt/sdcard/X-LOADER
~ # tocparser -r BKP_MINIT_1:/mnt/sdcard/BKP_MINIT_1
tocparser -r BKP_MINIT_1:/mnt/sdcard/BKP_MINIT_1
~ # tocparser -r PWR_MGT:/mnt/sdcard/PWR_MGT
tocparser -r PWR_MGT:/mnt/sdcard/PWR_MGT
~ # tocparser -r MEM_INIT:/mnt/sdcard/MEM_INIT
tocparser -r MEM_INIT:/mnt/sdcard/MEM_INIT
Click to expand...
Click to collapse
Hope this tool will be usefull for example reverse enginering first stage bootloader, maybe secu flag... etc!?? Enjoy in reverse enginering!
Source code is in: snowball-android-staging-20120201.tar.gz
munjeni arrived with a new tool...... thanks for this...... hope this will help some devs.....
R: Tool for low level flashing !
Wouldn't this be able to dump DRM keys before unlocking bootloader?
Sent from my Xperia S using xda app-developers app
mirhl said:
Wouldn't this be able to dump DRM keys before unlocking bootloader?
Sent from my Xperia S using xda app-developers app
Click to expand...
Click to collapse
Lol, No
Sent from my LT22i using Tapatalk 2
Anyone know how to decompile this?
Men what is this file needed to? what will he change? I ask for the response and I apologise for my English
XperianPro said:
Anyone know how to decompile this?
Click to expand...
Click to collapse
Decompile? Why you need to decompile that when you can see source code on http://igloocommunity.org/support/Android_Getting_started_with_GB
mirhl said:
Wouldn't this be able to dump DRM keys before unlocking bootloader?
Sent from my Xperia S using xda app-developers app
Click to expand...
Click to collapse
Good question! If you have ideas than for example you can reguest dump from users with locked bootloader and post it here so some one get it compare... etc!
kamileoo92 said:
Men what is this file needed to? what will he change? I ask for the response and I apologise for my English
Click to expand...
Click to collapse
If you not understand what this tool is than do not try! If you try that without knownledge than there is 90% possibility for hard bricking your phone!
munjeni said:
Decompile? Why you need to decompile that when you can see source code on http://igloocommunity.org/support/Android_Getting_started_with_GB
Click to expand...
Click to collapse
I meant files from phones memory.
For me can somebody answer?
I got some decompiled but I an unable to decompile x-loader still not know what is loading offset! But I am sure something must be interesting there! Its first stage bootloader, but where is seccond stage? Is it u-boot or... ?
munjeni said:
I got some decompiled but I an unable to decompile x-loader still not know what is loading offset! But I am sure something must be interesting there! Its first stage bootloader, but where is seccond stage? Is it u-boot or... ?
Click to expand...
Click to collapse
Im not sure but I think first one loads hardware and second one while second one checks is everything signed.
Not sure but I think its something like this.
want to find where is fastboot and dump all fastboot functions...etc, allso want to try something with dedicating recovery, allso secu flag...etc... have no time now for trying, but I have idea, want to lock my bootloader and research for secu flag!
In x-loader there is something like:
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00012690 00 00 00 00 52 44 48 53 50 01 00 01 02 00 00 00 ....RDHSP.......
000126A0 01 00 00 00 02 00 00 00 01 00 00 00 00 00 00 00 ................
000126B0 00 80 00 00 00 00 00 00 FF FF FF FF FF FF FF FF .€......˙˙˙˙˙˙˙˙
But maybe there is for example 0x01 for secu flag or something... need to compare dump from loocked/unlocked bootloader...need to dump u-boot (if exist), need to dump radio... need to dump part of memory with contained fastboot... did you know where lies u-boot?
Great news
Enviado desde mi ST25a usando Tapatalk 2
Nice..will try it
Sent From Heaven ST25i
Hi
I just changed some stuff like images in a kernel using Android Kernel Kitchen 0.3.1.
Now I wanna test my changes.
My questions is->
What are worst case scenarios possible?
I am ready to go for boot loops and etc. but are there any consequences that may cause real hard brick of my phone? (Like---> it will never start again! or you need to take it to service center for repair!)?
Jaskaran498 said:
Hi
I just changed some stuff like images in a kernel using Android Kernel Kitchen 0.3.1.
Now I wanna test my changes.
My questions is->
What are worst case scenarios possible?
I am ready to go for boot loops and etc. but are there any consequences that may cause real hard brick of my phone? (Like---> it will never start again! or you need to take it to service center for repair!)?
Click to expand...
Click to collapse
What you can expect are boot loops, inability to get even see the boot splash, non-working wifi/ USB / touch / camera/ anything that needs a driver, random reboots. Personal experience: yesterday I was playing with changing part of the initramfs without changing the whole boot.img. It turns out that I needed to update the header size and checksum. Without this, it would hang for some seconds and then reboot (or not start at all). This was all fixable from recovery.
What can happen if you are not careful is a brick because you flash the wrong partition. Otherwise, you can always enter recovery mode and flash the kernel (for the i9300, it is mmcblk0p5). If you are not sure, look for the magic ANDROID! header:
Code:
# dd bs=64 count=1 if=/dev/block/mmcblk0p5 2>/dev/null | hexdump -C
00000000 41 4e 44 52 4f 49 44 21 80 bc 44 00 00 80 00 40 |[email protected]|
00000010 2e 1e 05 00 00 00 00 41 00 00 00 00 00 00 f0 40 |[email protected]|
00000020 00 01 00 40 00 08 00 00 00 00 00 00 00 00 00 00 |[email protected]|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040
So, the absolute worst-case scenario is when you accidentally flash the wrong partition. If you picked your EFS partition and do not have a backup, then your IMEI and stuff are gone.
Note: be sure not to wipe your recovery partition (mmcblk0p6), that requires you restore the recovery using download mode (I have not experienced this yet).
Lekensteyn said:
What you can expect are boot loops, inability to get even see the boot splash, non-working wifi/ USB / touch / camera/ anything that needs a driver, random reboots. Personal experience: yesterday I was playing with changing part of the initramfs without changing the whole boot.img. It turns out that I needed to update the header size and checksum. Without this, it would hang for some seconds and then reboot (or not start at all). This was all fixable from recovery.
What can happen if you are not careful is a brick because you flash the wrong partition. Otherwise, you can always enter recovery mode and flash the kernel (for the i9300, it is mmcblk0p5). If you are not sure, look for the magic ANDROID! header:
Code:
# dd bs=64 count=1 if=/dev/block/mmcblk0p5 2>/dev/null | hexdump -C
00000000 41 4e 44 52 4f 49 44 21 80 bc 44 00 00 80 00 40 |[email protected]|
00000010 2e 1e 05 00 00 00 00 41 00 00 00 00 00 00 f0 40 |[email protected]|
00000020 00 01 00 40 00 08 00 00 00 00 00 00 00 00 00 00 |[email protected]|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040
So, the absolute worst-case scenario is when you accidentally flash the wrong partition. If you picked your EFS partition and do not have a backup, then your IMEI and stuff are gone.
Note: be sure not to wipe your recovery partition (mmcblk0p6), that requires you restore the recovery using download mode (I have not experienced this yet).
Click to expand...
Click to collapse
Kk, thanks.
But what do i do if it does not start at all like u said (what i want is that it should at least be able start in recovery or download if possible).
Since its my first time messing with kernel, i am total n00b then
If it cannot proceed to the "normal" boot, then get into recovery by holding Volume Up + Power + Home for ten seconds while booting (I usually do that when I see the Samsung logo end release when it has restarted, showing the logo again (about ten seconds).
From there, use Install from zip (if you have a "update zip" that contains boot.img and some metadata) or (what I do) use adb push to put the image in /tmp/. Then use dd to write the boot image. Example (I use Linux):
Code:
laptop$ adb push boot-new.img /tmp/boot.img
laptop$ adb shell
# cat /tmp/boot.img > /dev/block/mmcblk0p5
Just in case of hardware failure, I also verify the md5sum:
Code:
laptop$ md5sum boot-new.img
laptop$ du -b boot-new.img # determine file size, say 1234
(android) # dd if=/dev/block/mmcblk0p5 bs=1234 count=1 | md5sum
The two outputs must match, otherwise something went wrong (unlikely, but still).
Lekensteyn said:
If it cannot proceed to the "normal" boot, then get into recovery by holding Volume Up + Power + Home for ten seconds while booting (I usually do that when I see the Samsung logo end release when it has restarted, showing the logo again (about ten seconds).
From there, use Install from zip (if you have a "update zip" that contains boot.img and some metadata) or (what I do) use adb push to put the image in /tmp/. Then use dd to write the boot image. Example (I use Linux):
Code:
laptop$ adb push boot-new.img /tmp/boot.img
laptop$ adb shell
# cat /tmp/boot.img > /dev/block/mmcblk0p5
Just in case of hardware failure, I also verify the md5sum:
Code:
laptop$ md5sum boot-new.img
laptop$ du -b boot-new.img # determine file size, say 1234
(android) # dd if=/dev/block/mmcblk0p5 bs=1234 count=1 | md5sum
The two outputs must match, otherwise something went wrong (unlikely, but still).
Click to expand...
Click to collapse
I know all this but what i m saying is that can there be conditions where neither i will be able to boot recovery nor download (even by volume+power+home method)?
Unless you do really stupid things like overwriting /dev/block/mmcblk0 or other partitions on http://cleanimport.xda/index.php?threads/2362743/, you will be safe.
Jaskaran498 said:
I know all this but what i m saying is that can there be conditions where neither i will be able to boot recovery nor download (even by volume+power+home method)?
Click to expand...
Click to collapse
Recovery has it's own kernel. It doesn't use the one you're modifying
-----------------------
Sent via tapatalk.
I do NOT reply to support queries over PM. Please keep support queries to the Q&A section, so that others may benefit
In the spirit of the old TriangleAway here is how you can make the "FC N" disappear from your unlocked bootloader screen. The N is a number that gets bumped every time you "fastboot flash". This method requires a root shell, if you have busybox installed (e.g. from the Magisk module) it can done 100% on phone. Could help you out if you ever need warrantee service, or just don't like seeing the bootloader count how many times you've messed with the phone.
Code:
OnePlus7TProNR:/sdcard # dd if=/dev/block/by-name/param of=param.dd
2048+0 records in
2048+0 records out
1048576 bytes (1.0 M) copied, 0.017794 s, 56 M/s
# xxd -g 1 param.dd > param.xxd
Now use an editor (vim, nano, whatever) to look for this line in the file:
Code:
00003420: 00 00 00 00 01 00 00 00 01 00 00 00 17 00 00 00 ................
The flash counter is stored in the first non-zero bytes. Change them to zero like this:
Code:
00003420: 00 00 00 00 00 00 00 00 01 00 00 00 17 00 00 00 ................
Finally, flash the partition back, and voila, the "FC" line is gone from the bootloader. Note, these steps would have to be repeated every time you fastboot flash something.
Code:
OnePlus7TProNR:/sdcard # dd if=/dev/block/by-name/param of=param.dd
2048+0 records in
2048+0 records out
1048576 bytes (1.0 M) copied, 0.017794 s, 56 M/s
# xxd -r param.xxd > param-0.dd
# dd if=param-0.dd of=/dev/block/by-name/param
Wait....so does this get rid of the unlocked bootloader screen altogether?
lendawg said:
Wait....so does this get rid of the unlocked bootloader screen altogether?
Click to expand...
Click to collapse
No. Once you've used a "fastboot flash" command, you'll see a line on the bootloader/fastboot screen that says "FC 1".
If you fastboot flash something else, it increases to "FC 2" and so on. I think it persists even if you re-lock the bootloader as an indicator to the manufacturer and carrier that you've messed with your phone, and how many times.
This technique will make that counter go away, making it easier to re-lock the bootloader and make the phone appear unmodified, in case you ever need warrantee service.
There used to be a tool called "Triangle Away" that did something similar a few years ago, but it isn't supported anymore. But this technique does the same thing, you can read more about it here:
https://forum.xda-developers.com/galaxy-s2/orig-development/2014-01-15-triangleaway-v3-26-t1494114
This is just to remove the counter . Any warranty work will probably still be denied seeing you phone is on record as unlocked bootloader when you submit for the unlock.bin. And I'm sure the well I got the unlock.bin but never used it line will not work lol