can someone assist me in changing the nk.exe in a way that allows me to change the deviceid from PU10 to HERM100
i succeded in hexediting the hk.nba from PU10 to HERM with the confirmation that Getdevice data recognize it as HERM
http://wiki.xda-developers.com/index.php?pagename=GetDeviceData
there are 2 places in the nk.nba where the device type is found
00007074h: 48 00 45 00 52 00 4D ; H.E.R.M
00316c74h: 48 00 45 00 52 00 4D ; H.E.R.M
i need to get H.E.R.M.1.0.0 instead (6 bytes to insert)
00007050h: 2C 00 25 00 64 00 2C 00 20 00 4E 00 61 00 6D 00 ; ,.%.d.,. .N.a.m.
00007060h: 65 00 20 00 69 00 73 00 20 00 25 00 73 00 0D 00 ; e. .i.s. .%.s...
00007070h: 0A 00 00 00 48 00 45 00 52 00 4D 00 00 00 00 00 ; ....H.E.R.M.....
00007080h: 4F 45 4D 47 65 74 43 50 4C 44 5F 47 50 49 4F 28 ; OEMGetCPLD_GPIO(
after dumping the rom including the boot XIP i found that the nk.exe contains this data.
the reason to do it is to "help" bbconnect to recognize it as a hermes
anyone can assist me ?
It seems Kies use OBEX...
AT+SYNCML=MOBEXSTART
First time I saw OBEX was in Brew Mobile Commander in 2006.
Also there was an Plugin for Total Commander...
But this seems not work with S8500.
Other used Protocol is TFS... Samsungs Test Commands. For instance in TkFileExplorer_2.2.exe used.
Hmmm. I need more info/practice about OBEX...
Best Regards
TFS - I saw references to that on the boot loader stuff that was decrypted elsewhere on this forum... Tiny File System, Transparent File System.....?????
New year... old questions.
In Kies you can find several OBEX Commands... like:
m-obex/system/memory
m-obex/application/count
apps_c...
m-obex/fs/info
m-obex/fs/mem_size
In bada 2.0 it seems removed obex... replaced by other stuff...
Anyway. For learning I wish I could use obex Commands successfully.
At the moment no idea how.
Maybe someone could help me.
Best Regards
Edit 1.
Found something via Google...
http://wammu.eu/docs/manual/protocol/m-obex.html
But I sent on XXJL2 AT Command, but can't see any results...
AT+SYNCML=MOBEXSTART
For instance I use WinComm...
AT Commands work on my Port 5...
But if I send this:
AT+SYNCML=MOBEXSTART
AT Commands not more work on COM 5...
Also I get no answer for obex Commands like this:
m-obex/application/count
Is obex open new port?
Or if I sent on 5 I should receive on COM 5 ?
Again many Questions.
Thanx for reading.
Best Regards
todo: implement it in bterm
Code:
Request: AT
41 54 0D 0A
Answer: AT OK
41 54 0D 0D 0A 4F 4B 0D 0A
Request: ATZ
41 54 5A 0D 0A
Answer: ATZ OK
41 54 5A 0D 0D 0A 4F 4B 0D 0A
Request: AT+SYNCML=MOBEXSTART
41 54 2B 53 59 4E 43 4D 4C 3D 4D 4F 42 45 58 53 54 41 52 54 0D 0A
Answer: AT+SYNCML=MOBEXSTART OK
41 54 2B 53 59 4E 43 4D 4C 3D 4D 4F 42 45 58 53 54 41 52 54 0D 4F 4B 0D 0A
Request:
80 00 0F 11 00 20 00 46 00 08 4D 4F 42 45 58
Answer:
A0 00 14 10 00 20 00 CB 00 00 00 01 4A 00 08 4D 4F 42 45 58
#########################################
# Additional command goes here...
#########################################
Request:
81 00 03
Answer:
A0 00 03
Request: ATZ
41 54 5A 0D 0A
Answer: ATZ OK
41 54 5A 0D 0D 0A 4F 4B 0D 0A
commands examples
Code:
Request: m-obex/connection_packet
82 00 23 CB 00 00 00 01 42 00 1B 6D 2D 6F 62 65 78 2F 63 6F 6E 6E 65 63 74 69 6F 6E 5F 70 61 63 6B 65 74
Answer:
A0 00 03
Request: m-obex/security/privacylock
83 00 27 CB 00 00 00 00 42 00 1F 6D 2D 6F 62 65 78 2F 73 65 63 75 72 69 74 79 2F 70 72 69 76 61 63 79 6C 6F 63 6B 00
Answer:
A0 00 12 C3 00 00 00 02 4C 00 05 00 00 49 00 05 00 00
Request: m-obex/fs/privacy_lock
83 00 22 CB 00 00 00 00 42 00 1A 6D 2D 6F 62 65 78 2F 66 73 2F 70 72 69 76 61 63 79 5F 6C 6F 63 6B 00
Answer:
A0 00 0D C3 00 00 00 02 49 00 05 4E 4F *
Request: m-obex/application/count
83 00 27 CB 00 00 00 00 42 00 1C 6D 2D 6F 62 65 78 2F 61 70 70 6C 69 63 61 74 69 6F 6E 2F 63 6F 75 6E 74 00 4C 00 03
Answer:
A0 00 14 C3 00 00 00 04 4C 00 05 00 00 49 00 07 2C 00 00 00
Request: m-obex/system/imsi
83 00 21 CB 00 00 00 00 42 00 16 6D 2D 6F 62 65 78 2F 73 79 73 74 65 6D 2F 69 6D 73 69 00 4C 00 03
Answer: IMSI ;)
A0 00 1F C3 00 00 00 0F 4C 00 05 00 00 49 00 12 .......
Request: ƒm-obex/system/mnc
83 00 20 CB 00 00 00 00 42 00 15 6D 2D 6F 62 65 78 2F 73 79 73 74 65 6D 2F 6D 6E 63 00 4C 00 03
Answer: 02
A0 00 12 C3 00 00 00 02 4C 00 05 00 00 49 00 05 30 32
Request: ƒm-obex/system/csc
83 00 20 CB 00 00 00 00 42 00 15 6D 2D 6F 62 65 78 2F 73 79 73 74 65 6D 2F 63 73 63 00 4C 00 03
Answer: S8500OXAJID
A0 00 1B C3 00 00 00 0B 4C 00 05 00 00 49 00 0E 53 38 35 30 30 4F 58 41 4A 49 44
Request: m-obex/system/openapiversion
83 00 2B CB 00 00 00 00 42 00 20 6D 2D 6F 62 65 78 2F 73 79 73 74 65 6D 2F 6F 70 65 6E 61 70 69 76 65 72 73 69 6F 6E 00 4C 00 03
Answer: 1.2.0_1009152352_LIS_S8500XXJID_XEO
A0 00 33 C3 00 00 00 23 4C 00 05 00 00 49 00 26 31 2E 32 2E 30 5F 31 30 30 39 31 35 32 33 35 32 5F 4C 49 53 5F 53 38 35 30 30 58 58 4A 49 44 5F 58 45 4F
Request: m-obex/application/getinstallsetting
83 00 33 CB 00 00 00 00 42 00 28 6D 2D 6F 62 65 78 2F 61 70 70 6C 69 63 61 74 69 6F 6E 2F 67 65 74 69 6E 73 74 61 6C 6C 73 65 74 74 69 6E 67 00 4C 00 03
Answer:
A0 00 14 C3 00 00 00 04 4C 00 05 00 00 49 00 07 01 00 00 00
---------- Post added at 06:31 PM ---------- Previous post was at 06:29 PM ----------
PS. tested on bada 2.0
Thank you very much.
I got it now.
Tested on bada 1.x
Older then XXJL2 seems to have other syntax...
But I can confirm work also on XXKL6.
Wow. Every little mistake have lead to no further connection...
Best Regards
Oh "surprise"...
Again obelix power...
m-obex/system/restore/start
.
.
See here:
http://forum.xda-developers.com/showpost.php?p=21541765&postcount=4
Best Regards
When I was messing with BitPim earlier, I tried out the Protocol Analyser and got this:
18:52:09.717 Other CDMA Phone: Listing files in dir: '.efs_private'
18:52:09.717 Other CDMA Phone: sendbrewcommand Data - 20 bytes
<#! phones.p_brew.listfilerequest !#>
00000000 59 0b 00 00 00 00 0d 2e 65 66 73 5f 70 72 69 76 Y.......efs_priv
00000010 61 74 65 00 ate.
18:52:09.765 Other CDMA Phone: brew response Data - 17 bytes
<#! phones.p_brew.listfileresponse !#>
00000000 13 0b 00 00 00 0d 2e 65 66 73 5f 70 72 69 76 61 .......efs_priva
00000010 74 t
18:52:09.765 Other CDMA Phone: Failed to list files in dir .efs_private
18:52:09.780 Other CDMA Phone: Listing subdirs in dir: '.efs_private'
18:52:09.780 Other CDMA Phone: X recurse=0
18:52:09.780 Other CDMA Phone: sendbrewcommand Data - 20 bytes
<#! phones.p_brew.listdirectoryrequest !#>
00000000 59 0a 00 00 00 00 0d 2e 65 66 73 5f 70 72 69 76 Y.......efs_priv
00000010 61 74 65 00 ate.
18:52:09.780 Other CDMA Phone: brew response Data - 17 bytes
<#! phones.p_brew.listdirectoryresponse !#>
00000000 13 0a 00 00 00 0d 2e 65 66 73 5f 70 72 69 76 61 .......efs_priva
00000010 74 t
18:52:09.780 Other CDMA Phone: Failed to list dir .efs_private
18:52:11.015 Other CDMA Phone: Listing files in dir: 'CGPS_ME'
18:52:11.015 Other CDMA Phone: sendbrewcommand Data - 15 bytes
<#! phones.p_brew.listfilerequest !#>
00000000 59 0b 00 00 00 00 08 43 47 50 53 5f 4d 45 00 Y......CGPS_ME.
18:52:11.030 Other CDMA Phone: brew response Data - 47 bytes
<#! phones.p_brew.listfileresponse !#>
00000000 59 0b 00 00 00 00 00 0f 00 01 00 93 1a e0 00 00 Y...............
00000010 6c 00 00 bb 1a e0 00 08 16 43 47 50 53 5f 4d 45 l........CGPS_ME
00000020 2f 43 47 50 53 43 65 6c 6c 44 42 46 69 6c 65 /CGPSCellDBFile
18:52:11.030 Other CDMA Phone: sendbrewcommand Data - 15 bytes
<#! phones.p_brew.listfilerequest !#>
00000000 59 0b 01 00 00 00 08 43 47 50 53 5f 4d 45 00 Y......CGPS_ME.
18:52:11.046 Other CDMA Phone: brew response Data - 55 bytes
<#! phones.p_brew.listfileresponse !#>
00000000 59 0b 00 01 00 00 00 0f 00 01 00 93 1a e0 00 2c Y..............,
00000010 00 00 00 bb 1a e0 00 08 1e 43 47 50 53 5f 4d 45 .........CGPS_ME
00000020 2f 43 47 50 53 43 65 6c 6c 44 42 4f 74 61 50 6f /CGPSCellDBOtaPo
00000030 73 52 65 63 6f 72 64 sRecord
18:52:11.046 Other CDMA Phone: sendbrewcommand Data - 15 bytes
<#! phones.p_brew.listfilerequest !#>
00000000 59 0b 02 00 00 00 08 43 47 50 53 5f 4d 45 00 Y......CGPS_ME.
18:52:11.062 Other CDMA Phone: brew response Data - 47 bytes
<#! phones.p_brew.listfileresponse !#>
00000000 59 0b 00 02 00 00 00 0f 00 01 00 93 1a e0 00 3c Y..............<
00000010 00 00 00 bb 1a e0 00 08 16 43 47 50 53 5f 4d 45 .........CGPS_ME
00000020 2f 67 70 73 6f 66 66 73 65 74 73 2e 62 69 6e /gpsoffsets.bin
18:52:11.062 Other CDMA Phone: sendbrewcommand Data - 15 bytes
<#! phones.p_brew.listfilerequest !#>
00000000 59 0b 03 00 00 00 08 43 47 50 53 5f 4d 45 00 Y......CGPS_ME.
18:52:11.078 Other CDMA Phone: brew response Data - 3 bytes
<#! phones.p_brew.listfileresponse !#>
00000000 59 0b 1c Y..
18:52:11.092 Other CDMA Phone: Listing subdirs in dir: 'CGPS_ME'
18:52:11.092 Other CDMA Phone: X recurse=0
18:52:11.092 Other CDMA Phone: sendbrewcommand Data - 15 bytes
<#! phones.p_brew.listdirectoryrequest !#>
00000000 59 0a 00 00 00 00 08 43 47 50 53 5f 4d 45 00 Y......CGPS_ME.
18:52:11.092 Other CDMA Phone: brew response Data - 3 bytes
<#! phones.p_brew.listdirectoryresponse !#>
00000000 59 0a 1c Y..
18:52:12.953 Other CDMA Phone: Getting file contents 'CGPS_ME/gpsoffsets.bin'
18:52:12.953 Other CDMA Phone: sendbrewcommand Data - 27 bytes
<#! phones.p_brew.readfilerequest !#>
00000000 59 04 00 17 43 47 50 53 5f 4d 45 2f 67 70 73 6f Y...CGPS_ME/gpso
00000010 66 66 73 65 74 73 2e 62 69 6e 00 ffsets.bin.
18:52:12.983 Other CDMA Phone: brew response Data - 71 bytes
<#! phones.p_brew.readfileresponse !#>
00000000 59 04 00 00 00 3c 00 00 00 3c 00 ff ff 38 00 00 Y....<...<...8..
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 .......
Near the beginning of these, it says things about being unable to open up the .efs_private directory, along with its subfolders. If someone were able to open these, we may find something interesting. Hope this helps!
i got interest in:
p_brew.readfileresponse
if brew lets you load things. i can do test like i did with mtp, through raw USB.
I wondered the same thing about the listing of "brew" there. Can't wait to see if John finds anything.
Using BitPim, which (I believe, from my google searches) references QPST content, the .efs_private folder seems to be specific to QPST. If we're seeing an error trying to list that area, it's probably because bitpim is designed to look for some standard folders, which the Kin does not have.
if we had a worthwhile alternative to BitPim, we may be able to see what's in there. And when you said QPST, does that have anything to do with Qualcomm? I was also looking at the configuration settings for the phone's modem, and i think it mentioned that. So this file could contain hardware, storage, and other files that we could use to break through the restrictions on the phone.
Yes, many phones use Qualcomm hardware or functionality, including Verizon ones. Bitpim simply takes advantage of some common functionality between these phones.
Which file did you mean?
Hello.
I'm currently investigating the ZundDB.dat file located in \My Documents\Zune on the phone, this because I need to be able to edit the information in it for my new project (izPictureTool) for the purpose of organizing pictures on-device, in stead of syncing with Zune, organizing, and syncing it back.
If this file is understood and a library is built for editing its content, it will also make it possible to add music to the Zune player ON-DEVICE, which has been wanted for some time, it will also make it able to edit the tags for tracks ON-DEVICE.
Is there anyone with any knowledge about this file that could be useful?
The file "type/identifier" or what ever it's called is "ZMDB" which I believe is an acronym for Zune Media DataBase.
Here are the data bound to the picture albums I've synced to my phone, including the information about the pictures. Albumnames in BOLD/ITALIC and filenames in ITALIC.
Code:
4:7B40h: [B][I]4D 69 73 63[/I][/B] 00 00 00 00 14 00 00 4B 00 00 00 00 [B][I]Misc[/I][/B].......K....
4:7B50h: 00 52 6E E1 36 E5 CC 01 32 30 31 32 5F 30 32 00 .Rná6åÌ.2012_02.
4:7B60h: D2 00 00 43 C0 01 00 05 C3 01 00 0B 00 00 00 00 Ò..CÀ...Ã.......
4:7B70h: DD E2 01 00 00 52 6E E1 36 E5 CC 01 [I]43 61 6E 6F[/I] Ýâ...Rná6åÌ.[I]Cano[/I]
4:7B80h: [I]6E 20 50 6F 77 65 72 53 68 6F 74 20 53 58 31 31 n PowerShot SX11 [/I]
4:7B90h: [I]30 20 49 53 2E 6A 70 67[/I] 00 E0 A5 5D 59 00 00 00 [I]0 IS.jpg[/I].à¥]Y...
4:7BA0h: 00 00 00 00 00 00 00 00 00 10 14 01 00 00 00 04 ................
4:7BB0h: 15 80 02 00 00 04 01 82 CB 01 00 00 04 01 83 01 .€.....‚Ë.....ƒ.
4:7BC0h: 00 00 00 04 1E 5C 00 4D 00 79 00 20 00 44 00 6F .....\.M.y. .D.o
4:7BD0h: 00 63 00 75 00 6D 00 65 00 6E 00 74 00 73 00 5C .c.u.m.e.n.t.s.\
4:7BE0h: 00 5A 00 75 00 6E 00 65 00 5C 00 43 00 6F 00 6E .Z.u.n.e.\.C.o.n
4:7BF0h: 00 74 00 65 00 6E 00 74 00 5C 00 30 00 33 00 30 .t.e.n.t.\.0.3.0
4:7C00h: 00 30 00 5C 00 30 00 31 00 5C 00 74 00 68 00 75 .0.\.0.1.\.t.h.u
4:7C10h: 00 6D 00 62 00 73 00 5C 00 63 00 31 00 5F 00 74 .m.b.s.\.c.1._.t
4:7C20h: 00 68 00 75 00 6D 00 62 00 2E 00 6A 00 70 00 67 .h.u.m.b...j.p.g
4:7C30h: 00 00 00 6E 01 8B 00 00 C7 00 00 43 C0 01 00 05 ...n.‹..Ç..CÀ...
4:7C40h: C3 01 00 0B 00 00 00 00 41 20 00 00 80 BF A1 15 Ã.......A ..€¿¡.
4:7C50h: AF EA CC 01 [I]45 6B 65 6E C3 A4 73 73 74 75 67 61[/I] ¯êÌ.[I]Ekenässtuga[/I]
4:7C60h: [I]6E 2E 6A 70 67[/I] 00 F9 AA 2F 62 00 00 00 00 00 00 [I]n.jpg[/I].ùª/b......
4:7C70h: 00 00 00 00 00 00 10 14 01 00 00 00 04 15 DE 00 ..............Þ.
4:7C80h: 00 00 04 01 82 3A 00 00 00 04 01 83 01 00 00 00 ....‚:.....ƒ....
4:7C90h: 04 1E 5C 00 4D 00 79 00 20 00 44 00 6F 00 63 00 ..\.M.y. .D.o.c.
4:7CA0h: 75 00 6D 00 65 00 6E 00 74 00 73 00 5C 00 5A 00 u.m.e.n.t.s.\.Z.
4:7CB0h: 75 00 6E 00 65 00 5C 00 43 00 6F 00 6E 00 74 00 u.n.e.\.C.o.n.t.
4:7CC0h: 65 00 6E 00 74 00 5C 00 30 00 33 00 30 00 30 00 e.n.t.\.0.3.0.0.
4:7CD0h: 5C 00 30 00 31 00 5C 00 74 00 68 00 75 00 6D 00 \.0.1.\.t.h.u.m.
4:7CE0h: 62 00 73 00 5C 00 63 00 32 00 5F 00 74 00 68 00 b.s.\.c.2._.t.h.
4:7CF0h: 75 00 6D 00 62 00 2E 00 6A 00 70 00 67 00 00 00 u.m.b...j.p.g...
4:7D00h: 6E 01 8B 00 14 00 00 4B 00 00 00 00 80 39 2E 04 n.‹....K....€9..
4:7D10h: E3 F5 CA 01 32 30 31 30 5F 30 35 00 BE 00 00 43 ãõÊ.2010_05.¾..C
4:7D20h: C0 01 00 05 C4 01 00 0B 00 00 00 00 92 B0 01 00 À...Ä.......’°..
4:7D30h: 80 39 2E 04 E3 F5 CA 01 [I]56 43 2B 2B 2E 6A 70 67[/I] €9..ãõÊ.[I]VC++.jpg[/I]
4:7D40h: 00 1C E8 26 31 00 00 00 00 00 00 00 00 00 00 00 ..è&1...........
4:7D50h: 00 10 14 01 00 00 00 04 15 92 04 00 00 04 01 82 .........’.....‚
4:7D60h: DC 05 00 00 04 01 83 01 00 00 00 04 1E 5C 00 4D Ü.....ƒ......\.M
4:7D70h: 00 79 00 20 00 44 00 6F 00 63 00 75 00 6D 00 65 .y. .D.o.c.u.m.e
4:7D80h: 00 6E 00 74 00 73 00 5C 00 5A 00 75 00 6E 00 65 .n.t.s.\.Z.u.n.e
4:7D90h: 00 5C 00 43 00 6F 00 6E 00 74 00 65 00 6E 00 74 .\.C.o.n.t.e.n.t
4:7DA0h: 00 5C 00 30 00 33 00 30 00 30 00 5C 00 30 00 31 .\.0.3.0.0.\.0.1
4:7DB0h: 00 5C 00 74 00 68 00 75 00 6D 00 62 00 73 00 5C .\.t.h.u.m.b.s.\
4:7DC0h: 00 63 00 33 00 5F 00 74 00 68 00 75 00 6D 00 62 .c.3._.t.h.u.m.b
4:7DD0h: 00 2E 00 6A 00 70 00 67 00 00 00 6E 01 8B 00 00 ...j.p.g...n.‹..
4:7DE0h: 0C 00 00 45 9F 01 00 05 00 00 00 00 ...EŸ.......
Regards
Izaac
Have you tried using the CE database functions? The typical file extension for old CE databases is .VOL and for the new ones (Embedded Database) it's .EDB, but it doens't have to be those. If it works using either type of DB, that would give an easy and quick programmatic access.
I've already got a test library cooked up that can poke a database volume and figure out what tables it contains. I could try pointing it at this file...
Hello. Yes please do so and tell me what you find
Done some research to find out if it's an old CEDB or a newer EDB but I don't think it is, but I'm not sure thou, at least the first data in the file is ZMDB as you can see down below.
Code:
0000h: [B]5A 4D 44 42[/B] 01 00 00 00 90 4A 03 00 AC 07 00 00 [B]ZMDB[/B]....J..¬...
0010h: 92 00 00 00 C4 42 03 00 80 01 00 00 00 00 00 00 ’...ÄB..€.......
0020h: 5A 4D 65 64 05 00 00 00 D8 01 00 00 1D 04 00 00 ZMed....Ø.......
0030h: 00 00 00 00 4C F4 76 08 5A 41 72 72 00 D0 08 00 ....Lôv.ZArr.Ð..
0040h: 31 00 00 00 40 1F 00 00 D0 07 00 00 5A 41 72 72 [email protected]Ð...ZArr
0050h: 00 E0 04 00 00 00 00 00 A0 0F 00 00 D4 01 01 00 .à......*...Ô...
0060h: 5A 41 72 72 01 E0 04 00 00 00 00 00 A0 0F 00 00 ZArr.à......*...
0070h: 58 40 01 00 5A 41 72 72 02 E0 04 00 00 00 00 00 [email protected]à......
0080h: E8 03 00 00 DC 7E 01 00 5A 41 72 72 03 E0 04 00 è...Ü~..ZArr.à..
Regards
Izaac
ZMDB - Zune Music Database?
ZArr - Zune Artist information or Zune Album art?
Just guessing, no need to answer
As I said before
IzaacJ said:
The file "type/identifier" or what ever it's called is "ZMDB" which I believe is an acronym for Zune Media DataBase.
Click to expand...
Click to collapse
This database stores music, videos and pictures
Regards
Izaac
Sorry, missed it
From other side I think it can be more useful to search API to access that DB inside DLLs?
Yeah, but I doubt there'll be some functions for creating new albums and moving pictures to an other album, but I could be wrong.
Regards
Izaac
EDIT: Found some API calls in zuneapi.dll (requires ossvcs.dll to load in IDA Pro).
MediaApi_AddPhoto
MediaApi_AddPhotoFile
Really not that used to doing this kind of stuff, but I'm learning Didn't find anything related to deleting a picture/album, nor anything about creating an album or moving a picture from an album, but that's easy as adding the picture to the destination album, and deleting it from the previous one, when there are enough information to manage to do that
Regards
Izaac
it's also can be exposed as COM interface for example . . .
Can the DLL be imported via the DLLImport project, i would love to have it imported.
I wanna ask,
is galaxy w need link2sd installed?
what setting that would be good if installing link2sd?
Actually it depends on how much applications you want being installed on your phone but yes it worths installing it for at least 5 reasons:
Being able to mount to your computer your SD cards using the debug mode without stopping the applications that you should have moved to the SD card using the native App2SD.
Not being limited by the size of the /data partition because of the *.dex files generated for the dalvik cache.
You can move any kind of applications even those that are not movable to SD!
Link2SD includes free utilities like conversion of system application to user application (and vice versa) that you'll have to pay for with other solutions like Titanium Backup.
Avoiding slow downs because of the loop mounts created (Just run the "mount" command from an adb shell or terminal and you'll see).
Indeed I noticed a global slow down of my phone after I've started getting more and more applications being installed and beside I'm using some other tool to avoid push services and other unwanted background processes to be started by some applications, I've come to the conclusion that too many loop mounts because of the native App2SD is not good either (I suspect it takes over the RAM).
Actually the Link2SD FAQ will give you all the good reasons why to use it:
http://www.link2sd.info/faq
Recommendations:
I'd like to also share share my experience (I may move the following to another thread):
Recommend microSD cards:
Regarding the microSD card you can use even a 32 GB class 10.
The ones I recommend (32 GB class 10) are Samsung, SanDisk, Transcend (Those Transcend ones made in Korea are logically made by Samsung, the ones made in China are made by SanDisk).
Partitionning and formatting:
The tough part is the partitioning and formatting.
Out of the box, all the microSD cards are partitioned and formatted so that they are aligned with their erase block size (it can be 8 MiB, 12 MiB...)
Thus you'll have to consult so you'll know the erase block size:
the Linaro flash card survey:
https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey
the corresponding flashbench mailing list
http://lists.linaro.org/mailman/listinfo/flashbench-results
You can also use the flashbench tool to figure it out.
The problem is that you cannot create or resize the FAT32 partition using Windows (even with minitool partition or paragon partition manager), nor with Linux by using gparted or other because you won't get your partitions aligned with the erase blocks and thus you'll get bad performances and faster wearing of your card.
Backup:
Before formatting do a raw backup of the first 16 MiB (for the partitions table and the FAT32 description) using busybox dd on the phone itself or dd on Linux.
For example on the phone:
dd if=/dev/block/mmcblk1 of=/sdcard/mmcblk1-orig-1st-16MiB.img bs=4M count=4
Also you must keep using the default cluster size of 32 kiB because of optimization done at the level of Android and because smaller cluster size will mean more memory taken from the RAM - Actually the FAT is loaded in the RAM, so you must keep it not too big.
Formulas:
Then decide how much you need for the Link2SD partition - You can start with 1 GiB or so, personally I use about 2 GiB. You can check how much space is taken by the asec images to decide...
Now here comes some math (The formulas are to be used in LibreOffice Calc):
Partitioning:
We need to define the new size for the FAT32 partition at the beginning so it is aligned with the erase block size and so that the File Allocation Tables are located between the special offsets (especially true with SanDisk - for example the FAT must be located between the offsets at 4 MiB and 12 MiB, that's why most SD card have 4 MiB unpartitioned free space at the beginning).
Code:
new_fat32_partition_size = MROUND(whole_microsd_size - wanted_link2sd_partition_size + fat32_start_offset ; erase_block_size) - fat32_start_offset
With:
whole_microsd_size: The actual total size of the card - You can get it using fdisk.
wanted_link2sd_partition_size: The size you'd like for the Link2SD partition.
fat32_start_offset: The offset where the 1st FAT32 partition starts.
erase_block_size: The erase block size.
So for example for a SanDisk microSDHC 32 GB Class 10, we have an erase block size of 12 MiB (actually 3 times 4 MiB) and a FAT description that has to start at the offset at 4 MiB and then next erase block that starts at the offset at 12 MiB.
Therefore you'll have:
Code:
new_fat32_partition_size = MROUND(30,101,504 kiB - 1,061,376 kiB + 4,194,304 kiB ; erase_block_size) - 12 582 912 kiB = 30,101,504 kiB
Therefore using fdisk you should get something like the following when printing the partitions (p) - Don't forget to disable the DOS compatibility flag and use the sector as the unit:
Code:
Disk /dev/mmcblk0: 31.9 GB, 31914983424 bytes
4 heads, 16 sectors/track, 973968 cylinders, total 62333952 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9a064f9d
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 60211199 30101504 c W95 FAT32 (LBA)
/dev/mmcblk0p2 60211200 62333951 1061376 83 Linux
FAT32 formatting:
In order to use mkdosfs 3.0.9 or later with the right amount of reserved sectors so the root directory and data will start exactly at the next erase block offset.
The idea is to make so that the FATs ends exactly before that offset, but for that we need to know the size of one FAT.
Here is the formula based on mkdosfs source code, to calculate that needed number of reserved sectors:
Code:
total_number_of_sectors = total_number_of_blocks * block_size / sector_size
number_of_sectors_for_fats_and_data = total_number_of_sectors - MROUND(default_number_of_reserved_sectors ; cluster_size)
number_of_clusters = (number_of_sectors_for_fats_and_data * sector_size + number_of_fats * 8) / (cluster_size * sector_size + number_of_fats * 4)
fat_size = MROUND(CEILING((number_of_clusters + 2) * 4 / sector_size ; 1) ; cluster_size)
root_directory_offset = default_number_of_reserved_sectors + number_of_fats * fat_size
aligned_root_directory_offset = MROUND(root_directory_offset ; erase_block_size * 1024^2 / sector_size)
number_of_reserved_sectors = aligned_root_directory_offset - root_directory_offset + default_number_of_reserved_sectors
With:
sector_size: 512 bytes (Standard value)
block_size: 1,024 bytes (Standard value)
total_number_of_blocks: new_fat32_partition_size in kiB
default_number_of_reserved_sectors: 64 (can be 32)
cluster_size: 64 sectors (i.e. 32 kiB)
number_of_fats: 2 (Standard value)
So for example for that same card you'll get:
Code:
total_number_of_sectors = 60,203,008
number_of_reserved_sectors = 1,664
Therefore here is the command to format the FAT32 partition:
Code:
$> sudo mkdosfs -F 32 -s 64 -R 1664 -n EXTERNAL_SD -v /dev/mmcblk0p1
mkdosfs 3.0.9 (31 Jan 2010)
/dev/mmcblk0p1 has 4 heads and 16 sectors per track,
logical sector size is 512,
using 0xf8 media descriptor, with 60203008 sectors;
file system has 2 32-bit FATs and 64 sectors per cluster.
FAT size is 7360 sectors, and provides 940416 clusters.
There are 1664 reserved sectors.
Volume ID is 8aa89e36, volume label EXTERNAL_SD.
You can see that each FAT takes less than 3.6 MiB, so with 2 FATs and the reserved sector the FAT description takes less than 8 MiB.
You can then check using hexdump if indeed the root directory starts at the the 12 MiB offset (knowing that the partition begin at the 4 MiB offset - indeed 12 = 4 + 8).
For that let's read the first 13 MiB of the card:
Code:
$> sudo hd -n $[13*1024*1024] /dev/mmcblk0
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 82 |................|
000001c0 03 00 0c f8 95 a3 00 20 00 00 00 a0 96 03 00 f8 |....... ........|
000001d0 96 a3 83 1b f3 28 00 c0 96 03 00 64 20 00 00 00 |.....(.....d ...|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00400000 eb 58 90 6d 6b 64 6f 73 66 73 00 00 02 40 80 06 |[email protected]|
00400010 02 00 00 00 00 f8 00 00 10 00 04 00 00 00 00 00 |................|
00400020 00 a0 96 03 c0 1c 00 00 00 00 00 00 02 00 00 00 |................|
00400030 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00400040 00 00 29 e5 a5 dc 46 45 58 54 45 52 4e 41 4c 5f |..)...FEXTERNAL_|
00400050 53 44 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac |SDFAT32 ...w|.|
00400060 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 5e eb f0 32 |".t.V.......^..2|
00400070 e4 cd 16 cd 19 eb fe 54 68 69 73 20 69 73 20 6e |.......This is n|
00400080 6f 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 64 69 |ot a bootable di|
00400090 73 6b 2e 20 20 50 6c 65 61 73 65 20 69 6e 73 65 |sk. Please inse|
004000a0 72 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 66 6c |rt a bootable fl|
004000b0 6f 70 70 79 20 61 6e 64 0d 0a 70 72 65 73 73 20 |oppy and..press |
004000c0 61 6e 79 20 6b 65 79 20 74 6f 20 74 72 79 20 61 |any key to try a|
004000d0 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 00 00 00 00 |gain ... .......|
004000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
004001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00400200 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 |RRaA............|
00400210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
004003e0 00 00 00 00 72 72 41 61 7e 59 0e 00 03 00 00 00 |....rrAa~Y......|
004003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00400400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00400c00 eb 58 90 6d 6b 64 6f 73 66 73 00 00 02 40 80 06 |[email protected]|
00400c10 02 00 00 00 00 f8 00 00 10 00 04 00 00 00 00 00 |................|
00400c20 00 a0 96 03 c0 1c 00 00 00 00 00 00 02 00 00 00 |................|
00400c30 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00400c40 00 00 29 e5 a5 dc 46 45 58 54 45 52 4e 41 4c 5f |..)...FEXTERNAL_|
00400c50 53 44 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac |SDFAT32 ...w|.|
00400c60 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 5e eb f0 32 |".t.V.......^..2|
00400c70 e4 cd 16 cd 19 eb fe 54 68 69 73 20 69 73 20 6e |.......This is n|
00400c80 6f 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 64 69 |ot a bootable di|
00400c90 73 6b 2e 20 20 50 6c 65 61 73 65 20 69 6e 73 65 |sk. Please inse|
00400ca0 72 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 66 6c |rt a bootable fl|
00400cb0 6f 70 70 79 20 61 6e 64 0d 0a 70 72 65 73 73 20 |oppy and..press |
00400cc0 61 6e 79 20 6b 65 79 20 74 6f 20 74 72 79 20 61 |any key to try a|
00400cd0 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 00 00 00 00 |gain ... .......|
00400ce0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00400df0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00400e00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
004d0000 f8 ff ff 0f ff ff ff 0f f8 ff ff 0f ff ff ff 0f |................|
004d0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00868000 f8 ff ff 0f ff ff ff 0f f8 ff ff 0f ff ff ff 0f |................|
00868010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00c00000 45 58 54 45 52 4e 41 4c 5f 53 44 08 00 00 52 b3 |EXTERNAL_SD...R.|
We can see that indeed the root partition starts at the offset 0x00c00000 which is 12 MiB!
Also note that 0x00400000 is the 4 MiB offset, the beginning of the FAT32 partition...
You can try the hexdump against the backup you did and you'll see that the factory formatting is also with a number of reserved sector so that the root directory is aligned. For example I've found the root directory at the 12 MiB offset (of course) and for that they use 1,170 reserved sector (I've decoded the hexdump to get that value) which matches the formula. They also set 8,192 hidden sectors - that's more for compatibility with some cameras, we don't care here...
Link2SD formatting:
I use ext4 for that partition, I've got inspiration from http://blogofterje.wordpress.com/2012/01/14/optimizing-fs-on-sd-card/, however I'm not sure if indeed using the stride and the stripe-width options is really needed:
Code:
[FONT=Courier New]$ sudo mkfs.ext4 -O ^has_journal -E stride=4,stripe-width=512 -b 4096 -L Link2SD /dev/mmcblk0p2
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=Link2SD
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=4 blocks, Stripe width=512 blocks
66384 inodes, 265344 blocks
13267 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=272629760
9 block groups
32768 blocks per group, 32768 fragments per group
7376 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.[/FONT]
Anyway I consider the Link2SD partition is going to be used much more for read than write and we need the same file system that is used on the other partitions of the phone (i.e. ext4).
I hope it's not too complicated and that will help
Some other references:
http://android.bytearrays.com/android/align-your-sdcard-fat-and-ext-partition/
http://www.bradfordembedded.com/2011/12/format-an-sd-card-with-8-mib-aligned-partitions/
http://www.olpcnews.com/forum/index.php?topic=4993.0
http://www.patriotmemory.com/forums...ite-speed-by-aligning-FAT32&p=41521#post41521
http://forum.xda-developers.com/showthread.php?t=1224408
What a long and completed answer
I'll read and try to understand the way one-by-one. Thanks for sharing your knowledge!
Sent from my GT-I8150 using Tapatalk 2
v0rt3x said:
Actually it depends on how much applications you want being installed on your phone but yes it worths installing it for at least 5 reasons:
Being able to mount to your computer your SD cards using the debug mode without stopping the applications that you should have moved to the SD card using the native App2SD.
Not being limited by the size of the /data partition because of the *.dex files generated for the dalvik cache.
You can move any kind of applications even those that are not movable to SD!
Link2SD includes free utilities like conversion of system application to user application (and vice versa) that you'll have to pay for with other solutions like Titanium Backup.
Avoiding slow downs because of the loop mounts created (Just run the "mount" command from an adb shell or terminal and you'll see).
Indeed I noticed a global slow down of my phone after I've started getting more and more applications being installed and beside I'm using some other tool to avoid push services and other unwanted background processes to be started by some applications, I've come to the conclusion that too many loop mounts because of the native App2SD is not good either (I suspect it takes over the RAM).
Actually the Link2SD FAQ will give you all the good reasons why to use it:
http://www.link2sd.info/faq
Recommendations:
I'd like to also share share my experience (I may move the following to another thread):
Recommend microSD cards:
Regarding the microSD card you can use even a 32 GB class 10.
The ones I recommend (32 GB class 10) are Samsung, SanDisk, Transcend (Those Transcend ones made in Korea are logically made by Samsung, the ones made in China are made by SanDisk).
Partitionning and formatting:
The tough part is the partitioning and formatting.
Out of the box, all the microSD cards are partitioned and formatted so that they are aligned with their erase block size (it can be 8 MiB, 12 MiB...)
Thus you'll have to consult so you'll know the erase block size:
the Linaro flash card survey:
https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey
the corresponding flashbench mailing list
http://lists.linaro.org/mailman/listinfo/flashbench-results
You can also use the flashbench tool to figure it out.
The problem is that you cannot create or resize the FAT32 partition using Windows (even with minitool partition or paragon partition manager), nor with Linux by using gparted or other because you won't get your partitions aligned with the erase blocks and thus you'll get bad performances and faster wearing of your card.
Backup:
Before formatting do a raw backup of the first 16 MiB (for the partitions table and the FAT32 description) using busybox dd on the phone itself or dd on Linux.
For example on the phone:
dd if=/dev/block/mmcblk1 of=/sdcard/mmcblk1-orig-1st-16MiB.img bs=4M count=4
Also you must keep using the default cluster size of 32 kiB because of optimization done at the level of Android and because smaller cluster size will mean more memory taken from the RAM - Actually the FAT is loaded in the RAM, so you must keep it not too big.
Formulas:
Then decide how much you need for the Link2SD partition - You can start with 1 GiB or so, personally I use about 2 GiB. You can check how much space is taken by the asec images to decide...
Now here comes some math (The formulas are to be used in LibreOffice Calc):
Partitioning:
We need to define the new size for the FAT32 partition at the beginning so it is aligned with the erase block size and so that the File Allocation Tables are located between the special offsets (especially true with SanDisk - for example the FAT must be located between the offsets at 4 MiB and 12 MiB, that's why most SD card have 4 MiB unpartitioned free space at the beginning).
Code:
new_fat32_partition_size = MROUND(whole_microsd_size - wanted_link2sd_partition_size + fat32_start_offset ; erase_block_size) - fat32_start_offset
With:
whole_microsd_size: The actual total size of the card - You can get it using fdisk.
wanted_link2sd_partition_size: The size you'd like for the Link2SD partition.
fat32_start_offset: The offset where the 1st FAT32 partition starts.
erase_block_size: The erase block size.
So for example for a SanDisk microSDHC 32 GB Class 10, we have an erase block size of 12 MiB (actually 3 times 4 MiB) and a FAT description that has to start at the offset at 4 MiB and then next erase block that starts at the offset at 12 MiB.
Therefore you'll have:
Code:
new_fat32_partition_size = MROUND(30,101,504 kiB - 1,061,376 kiB + 4,194,304 kiB ; erase_block_size) - 12 582 912 kiB = 30,101,504 kiB
Therefore using fdisk you should get something like the following when printing the partitions (p) - Don't forget to disable the DOS compatibility flag and use the sector as the unit:
Code:
Disk /dev/mmcblk0: 31.9 GB, 31914983424 bytes
4 heads, 16 sectors/track, 973968 cylinders, total 62333952 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9a064f9d
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 60211199 30101504 c W95 FAT32 (LBA)
/dev/mmcblk0p2 60211200 62333951 1061376 83 Linux
FAT32 formatting:
In order to use mkdosfs 3.0.9 or later with the right amount of reserved sectors so the root directory and data will start exactly at the next erase block offset.
The idea is to make so that the FATs ends exactly before that offset, but for that we need to know the size of one FAT.
Here is the formula based on mkdosfs source code, to calculate that needed number of reserved sectors:
Code:
total_number_of_sectors = total_number_of_blocks * block_size / sector_size
number_of_sectors_for_fats_and_data = total_number_of_sectors - MROUND(default_number_of_reserved_sectors ; cluster_size)
number_of_clusters = (number_of_sectors_for_fats_and_data * sector_size + number_of_fats * 8) / (cluster_size * sector_size + number_of_fats * 4)
fat_size = MROUND(CEILING((number_of_clusters + 2) * 4 / sector_size ; 1) ; cluster_size)
root_directory_offset = default_number_of_reserved_sectors + number_of_fats * fat_size
aligned_root_directory_offset = MROUND(root_directory_offset ; erase_block_size * 1024^2 / sector_size)
number_of_reserved_sectors = aligned_root_directory_offset - root_directory_offset + default_number_of_reserved_sectors
With:
sector_size: 512 bytes (Standard value)
block_size: 1,024 bytes (Standard value)
total_number_of_blocks: new_fat32_partition_size in kiB
default_number_of_reserved_sectors: 64 (can be 32)
cluster_size: 64 sectors (i.e. 32 kiB)
number_of_fats: 2 (Standard value)
So for example for that same card you'll get:
Code:
total_number_of_sectors = 60,203,008
number_of_reserved_sectors = 1,664
Therefore here is the command to format the FAT32 partition:
Code:
$> sudo mkdosfs -F 32 -s 64 -R 1664 -n EXTERNAL_SD -v /dev/mmcblk0p1
mkdosfs 3.0.9 (31 Jan 2010)
/dev/mmcblk0p1 has 4 heads and 16 sectors per track,
logical sector size is 512,
using 0xf8 media descriptor, with 60203008 sectors;
file system has 2 32-bit FATs and 64 sectors per cluster.
FAT size is 7360 sectors, and provides 940416 clusters.
There are 1664 reserved sectors.
Volume ID is 8aa89e36, volume label EXTERNAL_SD.
You can see that each FAT takes less than 3.6 MiB, so with 2 FATs and the reserved sector the FAT description takes less than 8 MiB.
You can then check using hexdump if indeed the root directory starts at the the 12 MiB offset (knowing that the partition begin at the 4 MiB offset - indeed 12 = 4 + 8).
For that let's read the first 13 MiB of the card:
Code:
$> sudo hd -n $[13*1024*1024] /dev/mmcblk0
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 82 |................|
000001c0 03 00 0c f8 95 a3 00 20 00 00 00 a0 96 03 00 f8 |....... ........|
000001d0 96 a3 83 1b f3 28 00 c0 96 03 00 64 20 00 00 00 |.....(.....d ...|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00400000 eb 58 90 6d 6b 64 6f 73 66 73 00 00 02 40 80 06 |[email protected]|
00400010 02 00 00 00 00 f8 00 00 10 00 04 00 00 00 00 00 |................|
00400020 00 a0 96 03 c0 1c 00 00 00 00 00 00 02 00 00 00 |................|
00400030 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00400040 00 00 29 e5 a5 dc 46 45 58 54 45 52 4e 41 4c 5f |..)...FEXTERNAL_|
00400050 53 44 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac |SDFAT32 ...w|.|
00400060 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 5e eb f0 32 |".t.V.......^..2|
00400070 e4 cd 16 cd 19 eb fe 54 68 69 73 20 69 73 20 6e |.......This is n|
00400080 6f 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 64 69 |ot a bootable di|
00400090 73 6b 2e 20 20 50 6c 65 61 73 65 20 69 6e 73 65 |sk. Please inse|
004000a0 72 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 66 6c |rt a bootable fl|
004000b0 6f 70 70 79 20 61 6e 64 0d 0a 70 72 65 73 73 20 |oppy and..press |
004000c0 61 6e 79 20 6b 65 79 20 74 6f 20 74 72 79 20 61 |any key to try a|
004000d0 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 00 00 00 00 |gain ... .......|
004000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
004001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00400200 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 |RRaA............|
00400210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
004003e0 00 00 00 00 72 72 41 61 7e 59 0e 00 03 00 00 00 |....rrAa~Y......|
004003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00400400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00400c00 eb 58 90 6d 6b 64 6f 73 66 73 00 00 02 40 80 06 |[email protected]|
00400c10 02 00 00 00 00 f8 00 00 10 00 04 00 00 00 00 00 |................|
00400c20 00 a0 96 03 c0 1c 00 00 00 00 00 00 02 00 00 00 |................|
00400c30 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00400c40 00 00 29 e5 a5 dc 46 45 58 54 45 52 4e 41 4c 5f |..)...FEXTERNAL_|
00400c50 53 44 46 41 54 33 32 20 20 20 0e 1f be 77 7c ac |SDFAT32 ...w|.|
00400c60 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 5e eb f0 32 |".t.V.......^..2|
00400c70 e4 cd 16 cd 19 eb fe 54 68 69 73 20 69 73 20 6e |.......This is n|
00400c80 6f 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 64 69 |ot a bootable di|
00400c90 73 6b 2e 20 20 50 6c 65 61 73 65 20 69 6e 73 65 |sk. Please inse|
00400ca0 72 74 20 61 20 62 6f 6f 74 61 62 6c 65 20 66 6c |rt a bootable fl|
00400cb0 6f 70 70 79 20 61 6e 64 0d 0a 70 72 65 73 73 20 |oppy and..press |
00400cc0 61 6e 79 20 6b 65 79 20 74 6f 20 74 72 79 20 61 |any key to try a|
00400cd0 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 00 00 00 00 |gain ... .......|
00400ce0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00400df0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00400e00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
004d0000 f8 ff ff 0f ff ff ff 0f f8 ff ff 0f ff ff ff 0f |................|
004d0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00868000 f8 ff ff 0f ff ff ff 0f f8 ff ff 0f ff ff ff 0f |................|
00868010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00c00000 45 58 54 45 52 4e 41 4c 5f 53 44 08 00 00 52 b3 |EXTERNAL_SD...R.|
We can see that indeed the root partition starts at the offset 0x00c00000 which is 12 MiB!
Also note that 0x00400000 is the 4 MiB offset, the beginning of the FAT32 partition...
You can try the hexdump against the backup you did and you'll see that the factory formatting is also with a number of reserved sector so that the root directory is aligned. For example I've found the root directory at the 12 MiB offset (of course) and for that they use 1,170 reserved sector (I've decoded the hexdump to get that value) which matches the formula. They also set 8,192 hidden sectors - that's more for compatibility with some cameras, we don't care here...
Link2SD formatting:
I use ext4 for that partition, I've got inspiration from http://blogofterje.wordpress.com/2012/01/14/optimizing-fs-on-sd-card/, however I'm not sure if indeed using the stride and the stripe-width options is really needed:
Code:
[FONT=Courier New]$ sudo mkfs.ext4 -O ^has_journal -E stride=4,stripe-width=512 -b 4096 -L Link2SD /dev/mmcblk0p2
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=Link2SD
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=4 blocks, Stripe width=512 blocks
66384 inodes, 265344 blocks
13267 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=272629760
9 block groups
32768 blocks per group, 32768 fragments per group
7376 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.[/FONT]
Anyway I consider the Link2SD partition is going to be used much more for read than write and we need the same file system that is used on the other partitions of the phone (i.e. ext4).
I hope it's not too complicated and that will help
Some other references:
http://android.bytearrays.com/android/align-your-sdcard-fat-and-ext-partition/
http://www.bradfordembedded.com/2011/12/format-an-sd-card-with-8-mib-aligned-partitions/
http://www.olpcnews.com/forum/index.php?topic=4993.0
http://www.patriotmemory.com/forums...ite-speed-by-aligning-FAT32&p=41521#post41521
http://forum.xda-developers.com/showthread.php?t=1224408
Click to expand...
Click to collapse
what a nice answer... It's too complicated, but I think I can understand overall of that.. thanks mate
USB storage
Galaxy W has an internal USB Storage. Link2sd failed to move apps that have big database or library (like sygic) to the external memory but instead it was moved to the internal USB storage. How do I make Link2sd to move all the large apps to the external memory? Thanks in advance
Scootster said:
Galaxy W has an internal USB Storage. Link2sd failed to move apps that have big database or library (like sygic) to the external memory but instead it was moved to the internal USB storage. How do I make Link2sd to move all the large apps to the external memory? Thanks in advance
Click to expand...
Click to collapse
Swap the storage so that your external_sd will change place with the internal storage
Pressing "Thanks" button will be much appreciated if user's posts useful for you
swapped memory
reddvilzz said:
Swap the storage so that your external_sd will change place with the internal storage
Pressing "Thanks" button will be much appreciated if user's posts useful for you
Click to expand...
Click to collapse
I swapped memory before this but the phone perform not very good. It lagged very much in switching from one task to another.
If memory was to swapped, then there is no use for Link2sd isn't it? because all apps were installed directly to. external memory. Does memory card needs to be in 2 partition?
No, swapped ish juz useless trick and could break ur sd card.
Dwama said:
No, swapped ish juz useless trick and could break ur sd card.
Click to expand...
Click to collapse
What are you talking about?
There are 2 meanings of the word 'swap' for the W:
The 1st meaning is creating a swapfile and/or swap partition.
The 2nd meaning is to change the mount points of the internal SD and the external SD so that Android thought the external SD is the internal one (mounted at /sdcard) and the internal SD gets mounted to the external point ( /sdcard/external_sd)
The 1st meaning is the dangerous one. The 2nd meaning is instead very useful.
-- xda app / CM9b3 / DXKL1 / Galaxy W --