Related
Hi guys,
Not sure if this has been found yet, but in the dmesg logs you can see how the RAM on the Galaxy S is reserved.
This is from the JPK ROM:
[ 0.000000] S5PV210: PLL settings, A=800000000, M=667000000, E=96000000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x30ec2000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x40204000
[ 0.000000] s5pv210: 14680064 bytes system memory reserved for fimc0 at 0x42604000
[ 0.000000] s5pv210: 1048576 bytes system memory reserved for fimc1 at 0x43404000
[ 0.000000] s5pv210: 12582912 bytes system memory reserved for fimc2 at 0x43504000
[ 0.000000] s5pv210: 16777216 bytes system memory reserved for pmem at 0x332c2000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for pmem_gpu1 at 0x342c2000
[ 0.000000] s5pv210: 1536000 bytes system memory reserved for pmem_adsp at 0x34cc2000
[ 0.000000] s5pv210: 5132288 bytes system memory reserved for jpeg at 0x44104000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for texstream at 0x445e9000
[ 0.000000] s5pv210: 3145728 bytes system memory reserved for fimd at 0x44fe9000
[ 0.000000] s5pv210: 262144 bytes system memory reserved for wifi at 0x34e39000
[ 0.000000] Built 3 zonelists in Zone order, mobility grouping on. Total pages: 117856
[ 0.000000] Kernel command line: console=ttySAC2,115200 loglevel=4
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Memory: 80MB 256MB 128MB = 464MB total
[ 0.000000] Memory: 308048KB available (9224K code, 1910K data, 2868K init, 0K highmem)
I added up all the "system memory reserved for..." lines and got 151,633,920 bytes (144.6MB) reserved.
So the kernel can definitely see about 464MB of RAM in this case, but only 308,048KB is available.
hardcore said:
Hi guys,
Not sure if this has been found yet, but in the dmesg logs you can see how the RAM on the Galaxy S is reserved.
This is from the JPK ROM:
[ 0.000000] S5PV210: PLL settings, A=800000000, M=667000000, E=96000000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x30ec2000
[ 0.000000] s5pv210: 37748736 bytes system memory reserved for mfc at 0x40204000
[ 0.000000] s5pv210: 14680064 bytes system memory reserved for fimc0 at 0x42604000
[ 0.000000] s5pv210: 1048576 bytes system memory reserved for fimc1 at 0x43404000
[ 0.000000] s5pv210: 12582912 bytes system memory reserved for fimc2 at 0x43504000
[ 0.000000] s5pv210: 16777216 bytes system memory reserved for pmem at 0x332c2000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for pmem_gpu1 at 0x342c2000
[ 0.000000] s5pv210: 1536000 bytes system memory reserved for pmem_adsp at 0x34cc2000
[ 0.000000] s5pv210: 5132288 bytes system memory reserved for jpeg at 0x44104000
[ 0.000000] s5pv210: 10485760 bytes system memory reserved for texstream at 0x445e9000
[ 0.000000] s5pv210: 3145728 bytes system memory reserved for fimd at 0x44fe9000
[ 0.000000] s5pv210: 262144 bytes system memory reserved for wifi at 0x34e39000
[ 0.000000] Built 3 zonelists in Zone order, mobility grouping on. Total pages: 117856
[ 0.000000] Kernel command line: console=ttySAC2,115200 loglevel=4
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Memory: 80MB 256MB 128MB = 464MB total
[ 0.000000] Memory: 308048KB available (9224K code, 1910K data, 2868K init, 0K highmem)
I added up all the "system memory reserved for..." lines and got 151,633,920 bytes (144.6MB) reserved.
So the kernel can definitely see about 464MB of RAM in this case, but only 308,048KB is available.
Click to expand...
Click to collapse
That's interesting. If we take the line:
Memory: 80MB 256MB 128MB = 464MB total as the total memory
So adding it all up:
((464 * 1024 (total memory)) - (9224 + 1910 + 2868 (reserved for kernel) + (144.6 * 1024 (reserved by system) ))) / 1024 = 306 MB (available for apps)
However we should be seeing 512Mb not 464 as the total, so we are missing 48 Mb somewhere.
I still don't understand how the Galaxy Tab sees 444MB for actual applications.
http://www.youtube.com/watch?v=KoOWPjIel-c look at 4:40 in this video. it clearly shows how much RAM the tab is seeing.
Maybe we should poke inside the TAB's firmware to find out what is different?
The hardware is almost 1:1 with the SGS.
hardcore said:
Hi guys,
Not sure if this has been found yet, but in the dmesg logs you can see how the RAM on the Galaxy S is reserved.
Click to expand...
Click to collapse
Yes, see this thread starting here.
mtoneman said:
That's interesting. If we take the line:
Memory: 80MB 256MB 128MB = 464MB total as the total memory
So adding it all up:
((464 * 1024 (total memory)) - (9224 + 1910 + 2868 (reserved for kernel) + (144.6 * 1024 (reserved by system) ))) / 1024 = 306 MB (available for apps)
However we should be seeing 512Mb not 464 as the total, so we are missing 48 Mb somewhere.
Click to expand...
Click to collapse
It's probably the dalvic-cache!
Because "/system/build.prop" says: "dalvik.vm.heapsize=48m"
Just an idea
any improvements if we set an higher value for dalvik heapsize?
MCOGW said:
It's probably the dalvic-cache!
Because "/system/build.prop" says: "dalvik.vm.heapsize=48m"
Just an idea
Click to expand...
Click to collapse
This is the max heapsize for a single VM...meaning
the single application can allocate max of 48Mb heap before it gets out of memory.
This has nothing to do with RAM reservation
MCOGW said:
It's probably the dalvic-cache!
Because "/system/build.prop" says: "dalvik.vm.heapsize=48m"
Just an idea
Click to expand...
Click to collapse
No its not the dalvik heapsize. Changing that value doesn't give us more usable RAM.
I'm wondering about the Tab too. I was playing with a prototype and it definitely had more accessible RAM, as one poster said - more than 400MB. Would be good to see the dmesg boot log from a Tab to see what the system reserved and total memory is.
According to this:
http://forum.xda-developers.com/showthread.php?t=792512&page=11
there are one 2GBit (256MByte) and 2 x 1GBit (128MByte each) RAM chips totalling 512MBytes on the board. What we need to find out is why the kernel is reporting "Memory: 80MB 256MB 128MB".
i.e. what happened to the 48MByte on one of the 1GBit modules.
hardcore said:
No its not the dalvik heapsize. Changing that value doesn't give us more usable RAM.
Click to expand...
Click to collapse
I don't think it's that easy to (really) modifiy this value. I think you need a JTAG to modify this because these are direct parameters for the (smdkc110) chip.
So how did you manage (and verified) this?
If you would have read this thread:
http://forum.xda-developers.com/showthread.php?t=792512
You probably have read this:
http://forum.xda-developers.com/showpost.php?p=8325266&postcount=18
Ok it is not directly a "blackhole", but it is reserved.
The SGS kernel config tells you a bit more for what it is reserved:
Code:
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM=16384
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_GPU1=8192
CONFIG_ANDROID_PMEM_MEMSIZE_PMEM_ADSP=1800
...
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC0=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC1=1024
CONFIG_VIDEO_SAMSUNG_MEMSIZE_FIMC2=12288
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC0=32768
CONFIG_VIDEO_SAMSUNG_MEMSIZE_MFC1=32768
CONFIG_VIDEO_SAMSUNG_MEMSIZE_TEXSTREAM=10240
16 (16384)
+ 8 (8192)
+ 1,75 (1800)
+ 12 (12288)
+ 1 (1024)
+ 12 (12288)
+ 32 (32768)
+ 32 (32768)
+ 10 (10240)
112 mb
And 48 mb are not in the mem map, so 112+48 = 160
512-160=352mb
but we have a total of 325 mb (jm8)
352-325=27 are still missing
Have a look at /proc/iomem for these 27mb yourself.
And by reading that:
http://forum.xda-developers.com/showpost.php?p=8350492&postcount=126
jpk is only missing 32 mb = gpu.
So everything is fine on the ram amount, nothing to worry about.
Ok I just read up on the other threads (sorry missed those initially). If I understood correctly, the radio is separate and not visible to the linux kernel (unlike the other "reserved" blocks). This probably amounts to the 48MBytes we are not seeing in the Linux dmesg output.
Total guess: the difference in free ram between SGS and the Tab is probably that video ram for the SGS comes out of the system ram, while the Tab probably has a dedicated framebuffer+ram for it's graphics, probably because it's required for the bigger screen.
Why does Froyo have less available ram than Eclair though (hardware is the same)? In fact, why do different Eclair versions have different available ram? Is this just tweaking, and if so, can we not tweak it ourselves?
RyanZA said:
Why does Froyo have less available ram than Eclair though (hardware is the same)? In fact, why do different Eclair versions have different available ram? Is this just tweaking, and if so, can we not tweak it ourselves?
Click to expand...
Click to collapse
Cause it is a different OS? With more or newer components taking various amounts of memory?
This is like saying "why does Windows 7 leave you with less available memory than Windows XP". Ummm because it is not XP.
brunes said:
Cause it is a different OS? With more or newer components taking various amounts of memory?
This is like saying "why does Windows 7 leave you with less available memory than Windows XP". Ummm because it is not XP.
Click to expand...
Click to collapse
Mmm, and why on Nexus one there is the same RAM available in Eclair and Froyo?
And Windows 7 shows exactly the same amount of total RAM available as Windows XP.
burnes,
You are wrong.
brunes said:
Cause it is a different OS? With more or newer components taking various amounts of memory?
This is like saying "why does Windows 7 leave you with less available memory than Windows XP". Ummm because it is not XP.
Click to expand...
Click to collapse
The 'OS' is Linux! It's always important to remember this. Android is just an ecosystem (a number of apps and services) running on top of stock linux. Just because Android has gone up a version, doesn't mean the underlying system has changed! Any changes to Android components are actually all far outside the kernel, and will use up the same ram as other userland apps.
The reserved memory has nothing to do with Android, and has everything to do with the hardware drivers. Since the hardware hasn't changed, the question is why the graphics and low level drivers have been allocated more ram in Froyo than in Eclair.
Possible explanations are that Samsung gave more ram to graphics to help with... something? Maybe OpenGL ES 2 needs more ram, and performs worse than OpenGL ES 1, and so the OpenGL ES 2 driver needs to eat up more ram now? Or the Froyo drivers might just be badly optimized. In any case, it seems like we can tweak this stuff, because Samsung can tweak it.
The question is, how do we tweak it? In the kernel video drivers? Are there open specs available that we could use to work it out? And more questions I can't think of...
Well actually comparing dmesg and iomem outputs from JM8 and JPK would answer a lot of questions.
Speculating is leading us nowhere.
xan said:
Well actually comparing dmesg and iomem outputs from JM8 and JPK would answer a lot of questions.
Speculating is leading us nowhere.
Click to expand...
Click to collapse
I think a very deep look at this http://opensource.samsung.com/ (and a search for "GT-I9000") would answer lots of questions (only for Eclair atm)...
MCOGW said:
I think a very deep look at this http://opensource.samsung.com/ (and a search for "GT-I9000") would answer lots of questions (only for Eclair atm)...
Click to expand...
Click to collapse
<sarcasm>Wow thanks for the link, I'm sure none of the devs on here have bothered to check!</sarcasm>
Since many of ppl are concerning about the lags with RFS, and are looking for a faster solution, I performed some tests days before and I would like to share the results with all of you. the result was as expected (my expectation)
the test was conducted on /dbdata, using dd to read and write, and with different slice_sync and slice_async values.
According to lwn.net:
- slice_sync: How many msec a sync disk slice lasts
- slice_async: How many msec an async disk slice lasts
in froyo, the default value for slice_sync is 97, and slice_async is 39. while in eclair, they are 100 and 40 respectively.
and, the results were obtained by the average value under different file systems as below:
write: dd if=/dev/zero of=/dbdata/test count=25000 (using default bs=512)
read: dd if=/dbdata/test of=/dev/null
test1: default slice_sync (97), slice_async (39)
ext2 w=0.3563576, r=0.2172932
ext4 w=1.7057048, r=0.1286368
ext2 on ext4 w=0.2786272, r=0.1360666
ext2 on ext4 noatime nodiratime w=0.279215, r=0.124138
ext4 on ext2 w=0.4299866, r=0.1277804
test2: slice_sync (50), slice_async (20)
ext2 w=0.3883144,r=0.2209398
ext4 - omitted
ext2 on ext4 w=0.2743988,r=0.1343098
ext4 on ext2 w=0.4350612,r=0.2513572
test3: slice_sync (500), slice_async (200)
ext2 w=0.4159796, r=0.40419
ext4 - omitted
ext2 on ext4 - omitted
ext4 on ext2 w=0.4252074, r=0.2614818
obviously, the fastest one was ext2 on top of ext4, with only insignificant impact with noatime and nodiratime options (i cant believe it). this combination of file systems performed well as expected since while ext2 do somewhat like "blind read/write", the ext4 will hold the data b4 commit (PLS, pls dont argue ext2 and ext4 with me and that's why i described them very roughly... )
actually this was just for my own leasure but i think it may be useful to u guys as well so i decided to post it here for your ref
again, this is just for reference, and i am not prepared to discuss it further (sorry for my english, but no negative meaning at all)
ykk_five said:
ext2 w=0.3563576, r=0.2172932
ext4 w=1.7057048, r=0.1286368
Click to expand...
Click to collapse
Thanks for the tests! (0.3 vs 1.7? That's not the promised 'less than 5%' )
As far as the slice_sync and slice_async values, this seems to show that they have a fairly minor effect. Not that this test is that good for this kind of thing though - you should have used more than 1 file, you only use the file 'test'. Would be nice to re-run this using test1-test100000
RyanZA said:
Would be nice to re-run this using test1-test100000
Click to expand...
Click to collapse
yes, i'm waiting for yours!
what about ext2 on ext2?
sztupy said:
what about ext2 on ext2?
Click to expand...
Click to collapse
and for reference rfs,ext2 on rfs and ext4 on rfs should be tested as well
[Ultimate Lag Fix]
ykk_five said:
Since many of ppl are concerning about the lags with RFS, and are looking for a faster solution, I performed some tests days before and I would like to share the results with all of you. the result was as expected (my expectation)
the test was conducted on /dbdata, using dd to read and write, and with different slice_sync and slice_async values.
According to lwn.net:
- slice_sync: How many msec a sync disk slice lasts
- slice_async: How many msec an async disk slice lasts
in froyo, the default value for slice_sync is 97, and slice_async is 39. while in eclair, they are 100 and 40 respectively.
and, the results were obtained by the average value under different file systems as below:
write: dd if=/dev/zero of=/dbdata/test count=25000 (using default bs=512)
read: dd if=/dbdata/test of=/dev/null
test1: default slice_sync (97), slice_async (39)
ext2 w=0.3563576, r=0.2172932
ext4 w=1.7057048, r=0.1286368
ext2 on ext4 w=0.2786272, r=0.1360666
ext2 on ext4 noatime nodiratime w=0.279215, r=0.124138
ext4 on ext2 w=0.4299866, r=0.1277804
test2: slice_sync (50), slice_async (20)
ext2 w=0.3883144,r=0.2209398
ext4 - omitted
ext2 on ext4 w=0.2743988,r=0.1343098
ext4 on ext2 w=0.4350612,r=0.2513572
test3: slice_sync (500), slice_async (200)
ext2 w=0.4159796, r=0.40419
ext4 - omitted
ext2 on ext4 - omitted
ext4 on ext2 w=0.4252074, r=0.2614818
obviously, the fastest one was ext2 on top of ext4, with only insignificant impact with noatime and nodiratime options (i cant believe it). this combination of file systems performed well as expected since while ext2 do somewhat like "blind read/write", the ext4 will hold the data b4 commit (PLS, pls dont argue ext2 and ext4 with me and that's why i described them very roughly... )
actually this was just for my own leasure but i think it may be useful to u guys as well so i decided to post it here for your ref
again, this is just for reference, and i am not prepared to discuss it further (sorry for my english, but no negative meaning at all)
Click to expand...
Click to collapse
This was my finding also in [Ultimate Lag Fix] I am glad that someone else backed my findings !!!
mdalacu said:
This was my finding also in [Ultimate Lag Fix] I am glad that someone else backed my findings !!!
Click to expand...
Click to collapse
oh... i'm sorry... i didnt know that u've implemented it already
sztupy said:
and for reference rfs,ext2 on rfs and ext4 on rfs should be tested as well
Click to expand...
Click to collapse
did u read this b4?
http://forum.xda-developers.com/showthread.php?t=748596
In 2.6.32, mount options needs to be tuned, defaults are slow (long story between Linus and Ext4 developers)
If you want to be accurate, please use http://twitter.com/#!/supercurio/status/27729218185
This benchmark will probably not be representative of real lagfix using ext4 natively.
supercurio said:
In 2.6.32, mount options needs to be tuned, defaults are slow (long story between Linus and Ext4 developers)
If you want to be accurate, please use http://twitter.com/#!/supercurio/status/27729218185
This benchmark will probably not be representative of real lagfix using ext4 natively.
Click to expand...
Click to collapse
thx for ur info
but how about the data=writeback option which is by default =ordered? not needed in 2.6.32 anymore?
ykk_five said:
thx for ur info
but how about the data=writeback option which is by default =ordered? not needed in 2.6.32 anymore?
Click to expand...
Click to collapse
ordered is default still
writeback prolly faster (slightly less safe)
There is very little technical information on PIT files , so this thread is an attempt to find out some real details about PIT files, and perhaps eventually be able to create our own PIT files (by modifying Samsung ones, probably).
First, what we think we know PIT files do:
- PIT files only affect the 'STL' devices. That is, it affects the OneNAND and not the MoviNAND.
- PIT files appear to control the sizing (and maybe number) of STL devices that appear in Linux.
- PIT files appear to be used by Odin to map filenames inside .tar archives to STL partitions.
STL files are quite small, at under 2KB in size. Most of the file is made up of 0s. I have tried to compare the differences between the 512 513 and 803 PIT files we have available.
All the PIT files start with 76 98 34 12 0D - probably a signature to show it is a PIT file.
[Unimportant]
The 803 PIT file then has 00s all the way to the next common point. The 512 and 513 both have common data till the next common point - but this can't be too important as the 803 just has 00s.
The next common bit seems to read the following:
"oft IBL+PBL Server\90\To boot.bin inn; C:\Program Files\ESTsof
This probably indicates something to Odin. Strange that it has C:\Program Files\ - build path for the PIT file?
Next we have some 0s with common 1s inside them, followed by the word PIT, then more 0s, and then ries.pit. All common from here on with the words 'EFS' and 'efs.rfs'. Probably telling odin to map the efs.rfs file to the 'EFS' token. Tokens probably defined either in the kernel, or in the closed source STL library. More of the same of this, with 'SBL' 'sbl.bin', 'SBL2' 'sbl.bin' -- Both SBL and SBL2 map to the same sbl.bin file?
'PARAM' to 'param.lfs'
'KERNEL' to 'zImage'
'RECOVERY' to 'zImage' (this one is interesting - could we have seperate zImage and recovery? Could save some RAM here!)
[/Unimportant]
And now we'r onto the actual changes between the PIT files. 'FACTORYFS' maps to 'factoryfs.rfs'. However, before the FACTORYFS token, there are some bytes that likely control the partition sizes.
FACTORYFS
803 : A2 04 : 41476
512 : 7A 04 : 31236
513 : CA 04 : 51716
DBDATA
803 : F0 01 : 61441
512 : 18 02 : 6146
513 : C8 01 : 51201
CACHE
803 : 8C
512 : 8C
513 : 8C
MODEM
803 : 32
512 : 32
513 : 32
So there we have it. The only real changes between the PIT files are some seemingly garbage header information in 512/513 that is missing from 803, and FACTORYFS and DBDATA have different numbers -- probably sizes.
So assuming FACTORYFS maps onto /system, we can see that the only differences in the PIT files is moving space back and forwards between /dbdata and /system. The numbers themselves don't mean anything to me - can anybody work it out?
The numbers are little-endian, so you need to read them backwards per bytes. So instead of A12 it's actually 120A, etc. If you do so, you can see that the difference between 803 and 512 are actually minor, 40 "units" are shifted between probably DBDATA and SYSTEM.
Btw: doesn't the heimdal project klnow something about the pit files?
Nice, that gives us
FACTORYFS
803 : 04 A2 : 1186
512 : 04 7A : 1146
513 : 04 CA : 1226
DBDATA
803 : 01 F0 : 496
512 : 02 18 : 536
513 : 01 C8 : 456
1186+496=1682
1146+536=1682
1226+456=1682
So we have a match.
Now to work out why the fat.format can work with 536, but not with 496
EDIT: Also, need to determine why some roms require certain PIT files. Only possibility I can see is that junk in the header - could be some type of allow list for firmwares. The 803 PIT should therefore work on all firmwares, since it just has 00s. Maybe.
In 803.pit (compared to the .512 one) the system partition size has been increased by 10MB, while DBDATA partition size has been decreased the same amount (10MB).
PS: Dump the BML2 partition. The dump contains current partition mapping.
Hope this helps
RyanZA said:
Nice, that gives us
FACTORYFS
803 : 04 A2 : 1186
512 : 04 7A : 1146
513 : 04 CA : 1226
DBDATA
803 : 01 F0 : 496
512 : 02 18 : 536
513 : 01 C8 : 456
1186+496=1682
1146+536=1682
1226+456=1682
So we have a match.
Now to work out why the fat.format can work with 536, but not with 496
EDIT: Also, need to determine why some roms require certain PIT files. Only possibility I can see is that junk in the header - could be some type of allow list for firmwares. The 803 PIT should therefore work on all firmwares, since it just has 00s. Maybe.
Click to expand...
Click to collapse
I think the main cause is that some firmwares simply don't fit in the space reserved for them. Some of the m have larger system, some of them have larger dbdata partitions. Only a guess though, I think I start flashing pit files just for fun...
RazvanG said:
In 803.pit (compared to the .512 one) the system partition size has been increased by 10MB, while DBDATA partition size has been decreased the same amount (10MB).
Hope this helps
Click to expand...
Click to collapse
10MB = 40 units... That would give us 1 unit = 256kbyte. Nice.
So this means:
BOOT (bml01) = 01 = 1 = 0.25 MB (bootloader)
PIT (bml02) = 01 = 1 = 0,25 MB (the partition table)
EFS (bml03) = 28 = 40 = 10 MB (imei data and such)
SBL (bml04) = 05 = 5 = 1,25 MB (secondary bootloader)
SBL2 (bml05) = 05 = 5 = 1,25 MB (secondary bootloader backup)
PARAM (bml06) = 14 = 20 = 5 MB (the images shown when something is wrong)
KERNEL (bml07) = 1E = 30 = 7,5 MB (kernel image)
RECOVERY (bml08) = 1E = 30 = 7,5 MB (kernel image backup)
FACTORYFS (bml09) = 47A = 1146 = 286,5 MB (/system)
DBDATA (bml10) = 218 = 536 = 134 MB (/dbdata)
CACHE (bml11) = 8C = 140 = 35 MB (/cache)
MODEM (bml12) = 32 = 50 = 12,5 MB (software for wireless)
total: 501 MB
sztupy said:
I think the main cause is that some firmwares simply don't fit in the space reserved for them. Some of the m have larger system, some of them have larger dbdata partitions. Only a guess though, I think I start flashing pit files just for fun...
Click to expand...
Click to collapse
Not sure how true this can be -- Take 512 vs 513 for example. Newer Eclair roms stopped working on 513, and required 512. However, 513 has a smaller dbdata and larger system than 512. Since we know that a clean rom when flashed has a /dbdata of around 2mb, or 1% or so of available space, it can't be space related.
Must be more to than simple space allocations.
EDIT: And 501MB means we have space left over. Where is it hiding?
RyanZA said:
Not sure how true this can be -- Take 512 vs 513 for example. Newer Eclair roms stopped working on 513, and required 512. However, 513 has a smaller dbdata and larger system than 512. Since we know that a clean rom when flashed has a /dbdata of around 2mb, or 1% or so of available space, it can't be space related.
Must be more to than simple space allocations.
EDIT: And 501MB means we have space left over. Where is it hiding?
Click to expand...
Click to collapse
Yes, but the flashed dbdata.rfs was probably actually a large partition, that didn't fit into the allocated space.
Yes, the missing 11MB is strange, unless there is a 1MB "safety" gap between two partition (12 partitions = 11 gaps), or some other data.
EDIT: No, dumped BML0, it's only 501MB in length. The missing part might still be some space needed for the BML and STL to work.
Hi. I'm sorry for hijacking this thread but I need professional help from some geniuses (genii) and apparently you guys are firmware gurus.
Once you guys figure out how PIT files work, can you please help me figure out how to force flash Korean firmware onto an international phone without bricking it? The reason why I would like to do this, is because the Korean version has some really nice features for example native call recording (3rd party call recorders have bad quality). I made a thread for it here
Thanks a lot, köszönöm szépen!
Galaxy S I9000 PIT structure:
512.pit
PBL: 256KB (Primitive Bootloader)
PIT: 256KB
EFS: 10240KB (Non Volatile Memory)
SBL(1): 1280KB (Primary)
SBL(2): 1280KB (Backup)
PARAM: 5120KB
KERNEL(1): 7680KB (Primary)
KERNEL(2): 7680KB (Backup)
FACTORYFS: 293376KB
DBDATAFS: 137216KB
CACHE: 35840KB
MODEM: 12800KB
Total: 513024KB
513.pit
PBL: 256KB
PIT: 256KB
EFS: 10240KB
SBL(1): 1280KB
SBL(2): 1280KB
PARAM: 5120KB
KERNEL(1): 7680KB
KERNEL(2): 7680KB
FACTORYFS: 313856KB
DBDATAFS: 116736KB
CACHE: 35840KB
MODEM: 12800KB
Total: 513024KB
803.pit
PBL: 256KB
PIT: 256KB
EFS: 10240KB
SBL(1): 1280KB
SBL(2): 1280KB
PARAM: 5120KB
KERNEL(1): 7680KB
KERNEL(2): 7680KB
FACTORYFS: 303616KB
DBDATAFS: 126976KB
CACHE: 35840KB
MODEM: 12800KB
Total: 513024KB
In case there is backup blocks (e.g SBL and Kernel, Odin flashes them both while executing the flashing process).
dillovic said:
Hi. I'm sorry for hijacking this thread but I need professional help from some geniuses (genii) and apparently you guys are firmware gurus.
Once you guys figure out how PIT files work, can you please help me figure out how to force flash Korean firmware onto an international phone without bricking it? The reason why I would like to do this, is because the Korean version has some really nice features for example native call recording (3rd party call recorders have bad quality). I made a thread for it here
Thanks a lot, köszönöm szépen!
Click to expand...
Click to collapse
Galaxy S M110S is completely different hardware.
All other I9000 variants use Infineon X-Gold 616 baseband (Modem), while M110S uses Qualcomm baseband chip.
Made a try modifying the PIT file, to add more space to /dbdata and take away space from /system. I added around 25MB extra space to /dbdata.
Wasn't that hard actually, and I didn't encounter many problems (except the fact that the values are for the bare bml device, from which the stl has an extra 4-10% overhead so instead of the originally planed 35MB I could only spare 25).
If anyone's interested I can upload the modified pit and rom files.
Some remarks / questions:
- If we use the bare BML device instead of the STL I know we lose wear leveling (at least according to the rfs docs from samsung), but can't we use yaffs or similar on those devices? Or what if we (can we?) use cramfs for the /system on the BML, to gain even more space we could use for the /dbdata partition?
- The overhead the STL has seems a bit random to me. /system and /dbdata has a 4% overhead, while /cache a 10% one.
I'd be careful about resizing the partitions manually. Samsung should have aligned the partitions for best performance.
I'm not sure if its a placebo, but PIT 512 seems faster to me than PIT 803.
hardcore said:
I'd be careful about resizing the partitions manually. Samsung should have aligned the partitions for best performance.
I'm not sure if its a placebo, but PIT 512 seems faster to me than PIT 803.
Click to expand...
Click to collapse
Aligning should not be terribly hard -- we already specify using 256kb pieces instead of raw bytes. The alignment therefore is somewhere between 256kb and 4mb. If we align for 4mb, we align for everything smaller too. So as long as the numbers used are cleanly divisible by 4*4=16, it will be correctly aligned.
Flashing a PIT file with repartition checked seems to (according to docs) reset the wear leveling (the current record of what was written where, I guess), so you should not tick repartition if you are flashing many times in a row. (Many times is probably some very big number.)
I can't see why we couldn't use YAFFS or similar filesystem. Might work really well. I've got no experience setting up YAFFS though, and I don't believe it is trivial.
RyanZA said:
Aligning should not be terribly hard -- we already specify using 256kb pieces instead of raw bytes. The alignment therefore is somewhere between 256kb and 4mb. If we align for 4mb, we align for everything smaller too. So as long as the numbers used are cleanly divisible by 4*4=16, it will be correctly aligned.
Flashing a PIT file with repartition checked seems to (according to docs) reset the wear leveling (the current record of what was written where, I guess), so you should not tick repartition if you are flashing many times in a row. (Many times is probably some very big number.)
I can't see why we couldn't use YAFFS or similar filesystem. Might work really well. I've got no experience setting up YAFFS though, and I don't believe it is trivial.
Click to expand...
Click to collapse
I wonder if it is possible to make very small /system partition, and move it to mmcblk0 - since it is read only, performance will be ok. And make large dbdata partition, and keep /data/data there. That may be the ultimate lag fix
Sent from my GT-I9000 using XDA App
vitalij said:
I wonder if it is possible to make very small /system partition, and move it to mmcblk0 - since it is read only, performance will be ok. And make large dbdata partition, and keep /data/data there. That may be the ultimate lag fix
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
It is possible, but how would you flash a firmware then?
We are quickly approaching the 'throw it all away, and start from scratch with our own tools and bootloader.
RyanZA said:
It is possible, but how would you flash a firmware then?
We are quickly approaching the 'throw it all away, and start from scratch with our own tools and bootloader.
Click to expand...
Click to collapse
So are u guys planning to release the new galaxy s series phone??
You should rename it to galaxy-xda
So, from the info you have gathered, is there any point in using a PIT file when repartition is not checked?
huxflux2003 said:
So, from the info you have gathered, is there any point in using a PIT file when repartition is not checked?
Click to expand...
Click to collapse
I don't really see much point, but than again PIT file will tell odin (if your flashing pda) explicitly where the kernel should be flashed.
Also, I noticed that kernel partition is only 7.5-6 mb. Doest it mean that we cant use larger kernels (cos I think voodoo might me larger - hence the screen tear on boot).
http://code.google.com/p/badadroid/downloads/detail?name=bTerm_v0.13.zip&can=2&q=
sample bada terminal application. Connected device is detected automatically.
Available commands:
open - open the COM port
close - close the COM port
dump <address> <length> - dump NAND area
dumpram <address> <length> - dump RAM area
run <path_to_file> - execute the code from file
exit - terminate program
Keep in mind reading from invalid address cause Data Abort exception occurs.
Click to expand...
Click to collapse
Thank you very much b.kubica
As my brain is too small to try/understand all things.
Maybe others have tried?
Thanx in advance.
Best Regards
I am too stupid to read RAM...
http://forum.xda-developers.com/showthread.php?t=1093565
Maybe we can find in RAM uncompressed bada 2.0 stuff or for instance content of *.rbm files...
Maybe someone can please help me.
Thanx in advance.
Best Regards
bTerm works (for now) only in download mode. though implementation via AT command should be possible
Run executable
Hello, is run file implemented?
I tried to run programs on GT8500 (FW 1.2), and always get error like this:
>run Solitaires.exe
term_send: only sent 0 bytes of 8210
term_receive: ReadFile returned error!
OK - 0
>run LyricLegend.exe
term_send: only sent 0 bytes of 8209
term_receive: ReadFile returned error!
OK - 0
I needs a way for running console programs on device for unit testing. Is bTerm suitable for this task?
RealGred said:
I needs a way for running console programs on device for unit testing. Is bTerm suitable for this task?
Click to expand...
Click to collapse
Damn. No! It is not. And no, it is not possible in any other way.
http://code.google.com/p/badadroid/downloads/detail?name=bTerm_v0.15.zip&can=2&q=
New Version v0.15
Thank you.
Still unsolved problem because toooo small brain... which area to enter for RAM?
Best Regards
both 0x40000000 and 0x20000000 are valid start addresses
Any idea how to patch apps_compressed.bin of S8500BUKI1 to try this on bada 2.0
I know how to decyrept and encyrept with wave remaker
Also i have a little knowledge in using hex-editior
I can flash back XXJEE bootloader for its security hole
I just need address and data to write
Best Regards
follow these posts
http://forum.xda-developers.com/showpost.php?p=17872425&postcount=383
http://forum.xda-developers.com/showpost.php?p=17876128&postcount=385
I have only bada_term.fota from v0.11
Results...
In v0.13
Code:
>dumpram 20000000 100000
dumping 1.0 MB at 0x20000000: 14%
Error receiving packet (8192 bytes at 0x20026000). Received 0 bytes only.
>dumpram 40000000 100000
dumping 1.0 MB at 0x40000000: 16%
Error receiving packet (8192 bytes at 0x4002A000). Received 0 bytes only.
>dumpram 41000000 100000
dumping 1.0 MB at 0x41000000: 16%
Error receiving packet (8192 bytes at 0x4102A000). Received 0 bytes only.
>dumpram 42000000 100000
dumping 1.0 MB at 0x42000000: 16%
Error receiving packet (8192 bytes at 0x4202A000). Received 0 bytes only.
>dumpram 43000000 100000
dumping 1.0 MB at 0x43000000: 16%
Error receiving packet (8192 bytes at 0x4302A000). Received 0 bytes only.
>dumpram 44000000 100000
dumping 1.0 MB at 0x44000000: 16%
Error receiving packet (8192 bytes at 0x4402A000). Received 0 bytes only.
I can't read more then 177 KB...
I can see such text like:
is_dirty
is_syncing
.
.
.
With v0.15 seems no successfully connection possible.
close report success, but check false and commands also...
Code:
>open
COM5 port opened with success
>check
Phone response FAIL
My PC is XP powered.
Firmware is JE7... old T-Mobile bada 1.x...
Thanx.
Best Regards
u need to compile fota from sources - it is frequently updated so there is no sense to put assembled one in badadroid downloads
u need to compile fota from sources
Click to expand...
Click to collapse
Sorry, I'm an user. Not an Coder or user with Coding skills.
So my head explode before compiling something successfully.
There is enough space to upload FOTA + corresponding bTerm Version.
Maybe FOTA here as attachment.
Please.
Thanx.
Best Regards
fair enough
http://badadroid.googlecode.com/files/bada_term.zip
>open
COM5 port opened with success
>check
Phone response OK
Click to expand...
Click to collapse
Thank you very much, now v0.15 works on my XP with the new FOTA.
First success
Code:
>dumpram 20000000 8000000
dumping 128.0 MB at 0x20000000: 100%
Seems the 128 MB unit as bigger range interrupt...
I'll try now at 0x40000000
Best Regards
Edit 1.
Result:
Code:
>dumpram 40000000 10000000
dumping 256.0 MB at 0x40000000: 59%
Connection failed!
Abandoning dump with total received 0x0997C000 bytes.
Size is now around 157 MB...
Anyway...
I have some files for study.
Big thanx.
maybe I set to small timer intervals. I will increase it in next release
btw, u can start now dump from 0x4997C000 and then combine it with previous one
b.kubica said:
maybe I set to small timer intervals. I will increase it in next release
btw, u can start now dump from 0x4997C000 and then combine it with previous one
Click to expand...
Click to collapse
Working on S8530 ?
yes if you have correct fota assembled
b.kubica said:
yes if you have correct fota assembled
Click to expand...
Click to collapse
Its seem's my Xp have some PATH problem cant find COM says COM0, tested in another comp Win7 worked, Thank you.
its not path problem - looks like you have not installed samsung drivers
could you check something for me? connect phone in download mode, open regedit and go to HKLM\HARDWARE\DEVICEMAP\SERIALCOMM and send me all values stored in this key
b.kubica said:
its not path problem - looks like you have not installed samsung drivers
could you check something for me? connect phone in download mode, open regedit and go to HKLM\HARDWARE\DEVICEMAP\SERIALCOMM and send me all values stored in this key
Click to expand...
Click to collapse
Reinstalled driver properly now works but check fail
Compiled bada_term.asm on BADA2.01
Flashin bada_term.fota
DLMODE
i tried also CHARGING 0 same
; FOTA_SHADOWING equ 1
CHARGING_CONTROL equ 1
include 'S8530JPKA1.inc'
include 'macros.inc'
include 'vars.inc'
include 'functions.inc'
Maybe i need other firmeware ?
Im on original Orange firmware bada 1.2
Update: We have images, all images obtained for the partitions are uploaded here:
http://jellybean.dccontests.com/optimusg/
Partion 27 is recovery, and bootloader is partition 5.
I see from the AT&T thread that many people are getting their phones this weekend. If someone who gets the phone can send me an image of the bootloader I'd like to start getting a look at it.
If you need directions on how to do this, let me know. Currently I'm trying to figure out what the block devices are on the phone. If anyone knows this let me know, so I can direct someone (dbgeek) to get a dd of it.
Shelnutt2 said:
I see from the AT&T thread that many people are getting their phones this weekend. If someone who gets the phone can send me an image of the bootloader I'd like to start getting a look at it.
Click to expand...
Click to collapse
Bought mine 15 min ago at the AT&T store. How do I take an image?
dbgeek said:
Bought mine 15 min ago at the AT&T store. How do I take an image?
Click to expand...
Click to collapse
Nice.....have to wait...
Thank you for looking at this...hopefully it will be unlocked soon
Sent from my SGH-I897 using xda premium
I can walk you through it, but how much experience do you have with Linux/adb?
Sent from my cm_tenderloin using xda app-developers app
Shelnutt2 said:
I can walk you through it, but how much experience do you have with Linux/adb?
Sent from my cm_tenderloin using xda app-developers app
Click to expand...
Click to collapse
Sorry, but zero sums it up pretty well. I'm capable of navigating via DOS or UNIX commands if that helps in any way.
dbgeek said:
Sorry, but zero sums it up pretty well. I'm capable of navigating via DOS or UNIX commands if that helps in any way.
Click to expand...
Click to collapse
Go ahead and install the android sdk and adb, http://wiki.cyanogenmod.com/wiki/Howto:_Install_the_Android_SDK#Windows . Then root your phone, and install busybox.
Plug your phone into the computer, run adb devices in a command prompt. It should show your phone. Then run
Code:
adb shell
su
ls /dev
df
And post the output of the last two commands. I need to know a bit more about the phone so I can give you detailed steps and that will give me the info I need.
Sorry if anything is confusing, just let me know, I'm at work typing this
Does the ATT E970 have root? Answer my own question...Yes - method seems to work from Korean thread.
Code:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\>adb devices
List of devices attached
LG-E970-604d4e7f device
C:\>adb shell
[email protected]:/ $ su
su
ls /dev
ls /dev
d1|[email protected]:/ $ ls /dev
alarm
android_adb
android_mbim
apr_apps2
ashmem
binder
block
bus
ccid_bulk
ccid_ctrl
console
cpu_dma_latency
cpuctl
device-mapper
diag
dsp_debug
full
fuse
gemini0
genlock
graphics
hsicctl0
hsicctl1
hsicctl2
hsicctl3
hw_random
i2c-0
i2c-3
i2c-4
input
ion
keychord
kgsl-3d0
kmem
kmsg
lge_dm_tty0
log
mdm
media0
media1
media2
mem
msm_aac
msm_aac_in
msm_acdb
msm_amrnb
msm_amrnb_in
msm_amrwb
msm_amrwb_in
msm_camera
msm_dsps
msm_evrc
msm_evrc_in
msm_idle_stats0
msm_idle_stats1
msm_idle_stats2
msm_idle_stats3
msm_mp3
msm_multi_aac
msm_qcelp
msm_qcelp_in
msm_rotator
msm_rtac
msm_sps
msm_vidc_dec
msm_vidc_dec_sec
msm_vidc_enc
msm_vidc_reg
msm_wma
msm_wmapro
mtp_usb
network_latency
network_throughput
nmea
null
pipes
pn544
ppp
psaux
ptmx
pts
qmi0
qmi1
qmi2
qseecom
ramdump_dsps
ramdump_lpass
ramdump_riva
ramdump_smem-dsps
random
rfkill
rmnet_mux_ctrl
rtc0
siI-8334
smd1
smd11
smd2
smd21
smd22
smd27
smd3
smd36
smd4
smd5
smd6
smd7
smd_cxm_qmi
smd_pkt_loopback
smd_sns_adsp
smd_sns_dsps
smdcntl0
smdcntl1
smdcntl2
smdcntl3
smdcntl4
smdcntl5
smdcntl6
smdcntl7
smdcntl8
smem_log
snd
socket
tgt
tpa_amp
tspdrv
tty
tty0
tty1
tty10
tty11
tty12
tty13
tty14
tty15
tty16
tty17
tty18
tty19
tty2
tty20
tty21
tty22
tty23
tty24
tty25
tty26
tty27
tty28
tty29
tty3
tty30
tty31
tty32
tty33
tty34
tty35
tty36
tty37
tty38
tty39
tty4
tty40
tty41
tty42
tty43
tty44
tty45
tty46
tty47
tty48
tty49
tty5
tty50
tty51
tty52
tty53
tty54
tty55
tty56
tty57
tty58
tty59
tty6
tty60
tty61
tty62
tty63
tty7
tty8
tty9
ttyGS0
ttyUSB0
tun
uinput
urandom
usbf
usb_accessory
usb_autorun
usf1
v4l-subdev0
v4l-subdev1
v4l-subdev2
v4l-subdev3
v4l-subdev4
v4l-subdev5
v4l-subdev6
v4l-subdev7
v4l-subdev8
vcs
vcs1
vcs63
vcsa
vcsa1
vcsa63
video0
video1
video100
video2
video3
video38
video39
wcnss_wlan
xt_qtaguid
zero
[email protected]:/ $ df
dfdf
/system/bin/sh: dfdf: not found
127|[email protected]:/ $ df
df
Filesystem Size Used Free Blksize
/dev 911.16M 64.00K 911.10M 4096
/mnt/asec 911.16M 0.00K 911.16M 4096
/mnt/obb 911.16M 0.00K 911.16M 4096
/system 1.46G 1.06G 411.00M 4096
/data 11.30G 1.64G 9.65G 4096
/persist 7.86M 4.09M 3.77M 4096
/cache 787.39M 13.39M 774.00M 4096
/persist-lg 7.86M 4.11M 3.75M 4096
/mpt 31.48M 4.04M 27.45M 4096
/factory 15.73M 4.04M 11.69M 4096
/sns 7.86M 4.05M 3.81M 4096
/tombstones 251.97M 4.15M 247.82M 4096
/firmware 63.95M 52.84M 11.11M 16384
/mnt/sdcard 11.30G 1.64G 9.65G 4096
/mnt/sdcard/external_sd 14.70G 128.00K 14.70G 32768
[email protected]:/ $
mbonus, thank you for the output, unfortunatly it doesn't show me what the storage memory block devices are. I'm looking for something along the lines of "mmcblk" or others, try the following as root (su) in adb and post the output:
Code:
cat /etc/vold.fstab
The thing here is I just have to figure out which block device/partition holds the bootloader, so you can dump it to the sdcard (or internal storage) and then send it my way. The vold.fstab file should contain what the block devices are. They might be in a subfolder of /dev .
Also when you are roor you should have a '#' instead of a '$' at the beginning of the line in the shell.
ok I'll give it another shot when I get home
Sent from my LG-E970 using xda app-developers app
Thanks for the preliminary work, guys. I really want LTE, so I can't do the new Nexus. The Optimus has mediocre software and the One X+ still apparently has mediocre battery life, so getting this thing opened up to new ROMs might tip me over to the "G".
I thought I had root, but I still get the $ in adb shell
Idk I like the lg rom so far it is very smooth just gonna root and delete some bloatware
Sent from my LG Optimus G
Glad to hear you like the ROM. I'm just going from reviews, so hopefully I'll also like it when I see it in person. I was really hoping the One X+ would be my next phone, but the battery life and heat generation may be a deal breaker.
Edit: Plus, I'm hoping we can open the G up and maybe use some of the development for the Nexus ... except with LTE!
Ilkinansr92 said:
Idk I like the lg rom so far it is very smooth just gonna root and delete some bloatware
Sent from my LG Optimus G
Click to expand...
Click to collapse
let us know how bloat removal goes and what method
mbonus said:
I thought I had root, but I still get the $ in adb shell
Click to expand...
Click to collapse
Well does the `cat /etc/vold.fstab` yielf anything? You *might* not need root access to read it. If it doesn't work, or says file not find, run
Code:
ls /etc/
I appreciate you being the guinipig here, just trying find some way to figure out what the block devices are, as I don't see them listed under /dev.
Ilkinansr92 said:
Idk I like the lg rom so far it is very smooth just gonna root and delete some bloatware
Sent from my LG Optimus G
Click to expand...
Click to collapse
mbonus said:
let us know how bloat removal goes and what method
Click to expand...
Click to collapse
^^this, and additionally what you decided to remove as well, if you don't mind, sir.
Code:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Mike>adb shell
[email protected]:/ $ su
su
[email protected]:/ # ls /dev
ls /dev
alarm
android_adb
android_mbim
apr_apps2
ashmem
binder
block
bus
ccid_bulk
ccid_ctrl
console
cpu_dma_latency
cpuctl
device-mapper
diag
dsp_debug
full
fuse
gemini0
genlock
graphics
hsicctl0
hsicctl1
hsicctl2
hsicctl3
hw_random
i2c-0
i2c-3
i2c-4
input
ion
keychord
kgsl-3d0
kmem
kmsg
lge_dm_tty0
log
mdm
media0
media1
media2
mem
msm_aac
msm_aac_in
msm_acdb
msm_amrnb
msm_amrnb_in
msm_amrwb
msm_amrwb_in
msm_camera
msm_dsps
msm_evrc
msm_evrc_in
msm_idle_stats0
msm_idle_stats1
msm_idle_stats2
msm_idle_stats3
msm_mp3
msm_multi_aac
msm_qcelp
msm_qcelp_in
msm_rotator
msm_rtac
msm_sps
msm_vidc_dec
msm_vidc_dec_sec
msm_vidc_enc
msm_vidc_reg
msm_wma
msm_wmapro
mtp_usb
network_latency
network_throughput
nmea
null
pipes
pn544
ppp
psaux
ptmx
pts
qmi0
qmi1
qmi2
qseecom
ramdump_dsps
ramdump_lpass
ramdump_riva
ramdump_smem-dsps
random
rfkill
rmnet_mux_ctrl
rtc0
siI-8334
smd1
smd11
smd2
smd21
smd22
smd27
smd3
smd36
smd4
smd5
smd6
smd7
smd_cxm_qmi
smd_pkt_loopback
smd_sns_adsp
smd_sns_dsps
smdcntl0
smdcntl1
smdcntl2
smdcntl3
smdcntl4
smdcntl5
smdcntl6
smdcntl7
smdcntl8
smem_log
snd
socket
tgt
tpa_amp
tspdrv
tty
tty0
tty1
tty10
tty11
tty12
tty13
tty14
tty15
tty16
tty17
tty18
tty19
tty2
tty20
tty21
tty22
tty23
tty24
tty25
tty26
tty27
tty28
tty29
tty3
tty30
tty31
tty32
tty33
tty34
tty35
tty36
tty37
tty38
tty39
tty4
tty40
tty41
tty42
tty43
tty44
tty45
tty46
tty47
tty48
tty49
tty5
tty50
tty51
tty52
tty53
tty54
tty55
tty56
tty57
tty58
tty59
tty6
tty60
tty61
tty62
tty63
tty7
tty8
tty9
ttyGS0
ttyUSB0
tun
uinput
urandom
usb
usb_accessory
usb_autorun
usf1
v4l-subdev0
v4l-subdev1
v4l-subdev2
v4l-subdev3
v4l-subdev4
v4l-subdev5
v4l-subdev6
v4l-subdev7
v4l-subdev8
vcs
vcs1
vcs63
vcsa
vcsa1
vcsa63
video0
video1
video100
video2
video3
video38
video39
wcnss_wlan
xt_qtaguid
zero
[email protected]:/ # df
df
Filesystem Size Used Free Blksize
/dev 911.16M 64.00K 911.10M 4096
/mnt/asec 911.16M 0.00K 911.16M 4096
/mnt/obb 911.16M 0.00K 911.16M 4096
/system 1.46G 1.06G 411.95M 4096
/data 11.30G 1.74G 9.55G 4096
/persist 7.86M 4.09M 3.77M 4096
/cache 787.39M 17.28M 770.11M 4096
/persist-lg 7.86M 4.11M 3.75M 4096
/mpt 31.48M 4.04M 27.45M 4096
/factory 15.73M 4.04M 11.69M 4096
/sns 7.86M 4.05M 3.81M 4096
/tombstones 251.97M 4.15M 247.82M 4096
/firmware 63.95M 52.84M 11.11M 16384
/mnt/sdcard 11.30G 1.74G 9.55G 4096
/mnt/sdcard/external_sd 14.70G 9.28M 14.69G 32768
[email protected]:/ # cat /etc/vold.fstab
cat /etc/vold.fstab
# Copyright (c) 2011, Code Aurora Forum. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# * Redistributions in binary form must reproduce the above
# copyright notice, this list of conditions and the following
# disclaimer in the documentation and/or other materials provided
# with the distribution.
# * Neither the name of Code Aurora Forum, Inc. nor the names of its
# contributors may be used to endorse or promote products derived
# from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
# BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
# BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
# OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
# IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
# LGE_CHANGE For MTP
dev_mount sdcard2 /mnt/sdcard/external_sd auto /devices/platform/msm_sdcc.3/mmc_
host
[email protected]:/ #[COLOR="Silver"]
[SIZE=1]---------- Post added at 08:14 PM ---------- Previous post was at 08:13 PM ----------[/SIZE]
[/COLOR]Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Mike>adb shell
[email protected]:/ $ su
su
[email protected]:/ # ls /etc/
ls /etc/
DxHDCP.cfg
NOTICE.html.gz
OperatorPolicy.xml
UserPolicy.xml
amazon-kindle.properties
apns-conf.xml
apns_kr_mpdn.xml
apns_lgu_mpdn.xml
audio_effects.conf
bluetooth
capability.xml
dbus.conf
dcm_settings.xml
dhcpcd
efs.txt
es310.bin
event-log-tags
factory_reset_magic
fallback_fonts.xml
featureset.xml
firmware
format_first.sh
fota
gps.conf
hosts
init.goldfish.sh
init.lge_dut.bt.sh
init.qcom.bt.sh
init.qcom.coex.sh
init.qcom.efs.sync.sh
init.qcom.fm.sh
init.qcom.ftm_module.sh
init.qcom.ftm_module_out.sh
init.qcom.mdm_links.sh
init.qcom.modem_links.sh
init.qcom.post_boot.sh
init.qcom.sdio.sh
init.qcom.thermald_conf.sh
init.qcom.wifi.sh
init.wlan-on-off.sh
last_kmsg_backup.sh
logger_events.sh
logger_kernel.sh
logger_main.sh
logger_packet.sh
logger_radio.sh
logger_system.sh
logging_android.sh
logging_android_apart.sh
logging_kernel.sh
logging_kernel_apart.sh
logging_prepare.sh
mQ128-v44se.dls
media_profiles.xml
mkshrc
mts_mask
nfcee_access.xml
null_page
omadm
permissions
ppp
qosmgr_rules.xml
readahead_list.txt
save_kernel_log.sh
security
settings.xml
snd_soc_msm
system_fonts.xml
telephony.xml
thermald.conf
updatecmds
usf_post_boot.sh
vold.fstab
wfdconfig.xml
wifi
wiperconfig.xml
[email protected]:/ #
---------- Post added at 08:17 PM ---------- Previous post was at 08:14 PM ----------
mbonus said:
I thought I had root, but I still get the $ in adb shell
Click to expand...
Click to collapse
i'm such a newb, I didn't notice the phone had a superuser dialog box open requesting approval.
Okay the vold.fstab gave me a bit more info that I needed. Post the output of 'ls /devices/platform/' please. Again I do apologise for all the commands but this is set up a bit different than my heroc or touchpad, so just having to work through things through you, I do appreciate it though!
Also you can use the
Code:
[/code ] tags to post things in code boxes.
Sent from my cm_tenderloin using xda app-developers app
Shelnutt2 said:
Okay the vold.fstab gave me a bit more info that I needed. Post the output of 'ls /devices/platform/' please. Again I do apologise for all the commands but this is set up a bit different than my heroc or touchpad, so just having to work through things through you, I do appreciate it though!
Also you can use the
Code:
[/code ] tags to post things in code boxes.
Sent from my cm_tenderloin using xda app-developers app[/QUOTE]
Hey Shelnutt, thanks for jumping on this so early. Really thinkin about making this my next device and getting the bootloader unlocked will seal the deal.
Based on what you've seen so far, do you think any progress can be made?
I'd be willing to get the device and be a guinea pig as well....
Click to expand...
Click to collapse