Related
:? Dear All
Hope this message reaches you'll in good health and best of spirits.
I am new to this forum, so please help me.
After upgrading to WM2005 and after installing Hima DOC Tools v1.0, My O2 Xda II has become slow and my Storage Memory has decreased from 32.00 MB to 7.40 MB. When I install any program and / or put any Data in the Main Memory in place of Storage Card (SD Card), it reduces the Storage Memory, I thought the Program Memory usually reduces instead of Storage Memory.
Please clarify my doubts and if there is any procedure to increase the Storage Memory to 32.00 MB or default of 64 MB, please explain how to do it in simple manner, since I am just an end user, will not understand technical language.
The details of my o2 Xda II after upgrading to WM 2005 is :
VERSION
-------
ROM Version: 1.60b.96WWE
ROM date: 04/22/05
Radio Version: 1.18.00
Protocol Version: 1337.38
HARDWARE
--------
CPU: Intel(R) PXA263
Speed: 400 MHz.
RAM Size: 128 MB
Flash Size: 32 MB
Flash Chip Type: 28F128K3
Data Bus: 32 Bits
Storage Size: 30.53 MB
LCD: 240 x 320 TFT
Colors: 65536
IDENTITY
--------
Model No. PH10B
Platform: Pocket PC
I once again request you to help me.
Best Wishes
Dineshchand Nahar
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>
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).
!!!!Attention!!!!
This is an Testversion !use at your own risk! in worst case a complete data corruption could happen! Make an Backup before you start!
In my V5 testrom with kernel alpha2 wifi seems only to work with static ip! Please give me some feedback if this occours on other roms too (The wifi dhcp issue was not kernel related! It was an permission problem in my rom!)
The 2nd testversion only for users of my v4/v5a1 cwm rom is here:
http://forum.xda-developers.com/showpost.php?p=10302658&postcount=1
The 2nd testversion for all other MAGLDR CWM roms is here:
https://rapidshare.com/files/3354631926/io_test2_30.05.11_for_cwm_roms.zip (new version 30.05.2011 fix root permissions if su is in /system/bin)
(no need to update if you already use v2 and root is working)
mirror
http://www.multiupload.com/K6JGA7G616 (old v2! can break root if the su binary is in /system/bin!)
Test2 for cLK comes soon!
Changes Test2:
Slowdowns on long uptime / random reboots should be fixed
Ext4 now handles ext2/3 too
Removed delayed metadata write
The following files gets installed/replaced:
/boot/zImage
/system/etc/sysctl.conf
/system/etc/mke2fs.conf
/system/lib/modules/*.ko
And newest e2fsprogs in /system/bin/
For best performance on ext4 partition your rom should have sysctl.conf support
(This package should work on most froyo roms. But I did not test it on Gingerbread... Because of some user reports it seems that there are problems on gingerbread rom´s... Tomorrow I make some tests on a few gingerbread roms...)
With kernel 2.6.32 very bad ssd performance is a known problem...
I benchmarked my hd2 with the result that high I/O on sdcard causes very high iowait which can slow down the device performance (slow reaction/wakeup lag)
I did many many tests (different i/o schedulers, governors, vm settings, mount options, different block sizes) with nearly the same high iow...
I´m near to release a fix...
But I did many (sometime qick and dirty) changes in kernel src.
Now I have to find out what´s the related change...
You could help my by testing your device with the attached script and post the logs here to see if this affects all sdcard/kernel´s and possible other devices as the hd2
Here are a little preview of my attached logs:
With untouched kernel
Code:
User 0%, System 18%, IOW 81%, IRQ 0%
User 1 + Nice 0 + Sys 56 + Idle 0 + IOW 249 + IRQ 0 + SIRQ 0 = 306
Code:
209715200 bytes transferred in 61.567 secs (3406292 bytes/sec)
With modified kernel:
Code:
User 0%, System 23%, IOW 2%, IRQ 0%
User 2 + Nice 0 + Sys 75 + Idle 229 + IOW 9 + IRQ 0 + SIRQ 0 = 315
Code:
209715200 bytes transferred in 59.880 secs (3502257 bytes/sec)
sounds promising,
il give this a shot 2moro, n post logs, need a bit more details on how to test script
kam333 said:
sounds promising,
il give this a shot 2moro, n post logs, need a bit more details on how to test script
Click to expand...
Click to collapse
you need to have adb (android sdk) installed and working.
- download and unpack the testscript.sh.zip
- open cmd / Shell and go to the testscript.sh location
- type: adb remount
- type: adb push testscript.sh /system/bin/
- type: adb shell
- type: chmod 777 /system/bin/testscript.sh
- type: testscript.sh (you need 200mb free space on sdcard)
- the test takes about 1-2 min. Don´t touch your device!
- now you have an file iolog.tar.gz on your sdcard
Thanks for the details
Heres my iolog
Quick question, could this also help to reduced the lag after installing apks from sd card or the market?
kam333 said:
Thanks for the details
Heres my iolog
Quick question, could this also help to reduced the lag after installing apks from sd card or the market?
Click to expand...
Click to collapse
That was one reason to start this work...
Thx for your test.
And I tougt my iowait is high and the write performance is bad...
If you want you can test again with changed kernel in a few days. But then you should send me an copy from /proc/config.gz that I can compile an kernel with your config to ensure its working with your rom.
And make sure to backup your complete sdcard before... If something is wrong it could cause an complete data corruption in worst case...
bauner said:
That was one reason to start this work...
Thx for your test.
And I tougt my iowait is high and the write performance is bad...
If you want you can test again with changed kernel in a few days. But then you should send me an copy from /proc/config.gz that I can compile an kernel with your config to ensure its working with your rom.
And make sure to backup your complete sdcard before... If something is wrong it could cause an complete data corruption in worst case...
Click to expand...
Click to collapse
Ha... is mine that bad!?
its the thing i dislike the most about hd2, often takes 2- 3mins to settle after installing something.
i always keep a back up of my sd, so yeh id like to test your modified kernel, thnx
just a heads up... you might get a higher response if your title mentions "fix wake up lag" or even post in dev section.
kam333 said:
Ha... is mine that bad!?
its the thing i dislike the most about hd2, often takes 2- 3mins to settle after installing something.
i always keep a back up of my sd, so yeh id like to test your modified kernel, thnx
just a heads up... you might get a higher response if your title mentions "fix wake up lag" or even post in dev section.
Click to expand...
Click to collapse
your iowait is about 100 higher as on my tests and the you need 1m 54.26s to write 200mb which is about 50% of my results.
can you post the output of
- mount
- df
did you have many apps running in backround while doing the test?
what sdcard do you use?
bauner said:
can you post the output of
- mount
- df
Click to expand...
Click to collapse
sure, what are the commands to get the output?
im using a sandisk 16gb class 4, & have around 20 background apps running.
kam333 said:
sure, what are the commands to get the output?
im using a sandisk 16gb class 4, & have around 20 background apps running.
Click to expand...
Click to collapse
I use the same card...
connect your device to pc
and type: adb shell
next type: mount
(you can also write the output direct to an file on sdcard with this: mount > /mnt/sdcard/anyname.log )
and next type: df (or df > /mnt/sdcard/anothername.log )
Here's the logs
prob got more installed than i use tho
kam333 said:
Here's the logs
prob got more installed than i use tho
Click to expand...
Click to collapse
thx
your ext4 partition is mounted:
/dev/block/mmcblk0p2 /data ext4 rw,nosuid,nodev,noatime,nodiratime,commit=19,barrier=0,data=ordered,noauto_da_alloc 0 0
this should give you an very good performance on /data partition but with the risk of database/file corruption is higher if an unexpected shutdown (by removing battery on running device or system crashes) occur
bauner said:
thx
your ext4 partition is mounted:
/dev/block/mmcblk0p2 /data ext4 rw,nosuid,nodev,noatime,nodiratime,commit=19,barrier=0,data=ordered,noauto_da_alloc 0 0
this should give you an very good performance on /data partition but with the risk of database/file corruption is higher if an unexpected shutdown (by removing battery on running device or system crashes) occur
Click to expand...
Click to collapse
cheers,
hope u get it sorted.
kam333 said:
cheers,
hope u get it sorted.
Click to expand...
Click to collapse
i´m getting closer...
im a zero in comand lines in android/linux, i tested my 2 sd cards with crystaldiskmark, hope this info can be useful to you, having lags with 16gb kingston sd card:
-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 7.055 MB/s
Sequential Write : 4.135 MB/s
Random Read 512KB : 7.066 MB/s
Random Write 512KB : 0.671 MB/s
Random Read 4KB (QD=1) : 1.780 MB/s [ 434.6 IOPS]
Random Write 4KB (QD=1) : 0.006 MB/s [ 1.4 IOPS]
Random Read 4KB (QD=32) : 1.821 MB/s [ 444.6 IOPS]
Random Write 4KB (QD=32) : 0.006 MB/s [ 1.4 IOPS]
Test : 500 MB [I: 31.2% (4.6/14.9 GB)] (x5)
Date : 2011/04/19 22:56:47
OS : Windows Vista Home Premium Edition SP2 [6.0 Build 6002] (x86)
16gb class4 kingston
-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 2.184 MB/s
Sequential Write : 5.750 MB/s
Random Read 512KB : 2.182 MB/s
Random Write 512KB : 1.682 MB/s
Random Read 4KB (QD=1) : 1.535 MB/s [ 374.7 IOPS]
Random Write 4KB (QD=1) : 0.017 MB/s [ 4.2 IOPS]
Random Read 4KB (QD=32) : 1.077 MB/s [ 262.9 IOPS]
Random Write 4KB (QD=32) : 0.065 MB/s [ 15.8 IOPS]
Test : 500 MB [I: 76.4% (5798.1/7585.2 MB)] (x5)
Date : 2011/04/19 23:59:57
OS : Windows Vista Home Premium Edition SP2 [6.0 Build 6002] (x86)
daneelec 8gb class4
I´m using sd builds..
Desire HD build compatible ?
white-energy said:
Desire HD build compatible ?
Click to expand...
Click to collapse
I tested the changes until now only with my stock desire mod, but it should work for all roms
bauner said:
you need to have adb (android sdk) installed and working.
- download and unpack the testscript.sh.zip
- open cmd / Shell and go to the testscript.sh location
- type: adb remount
- type: adb push testscript.sh /system/bin/
- type: adb shell
- type: chmod 777 /system/bin/testscript.sh
- type: testscript.sh (you need 200mb free space on sdcard)
- the test takes about 1-2 min. Don´t touch your device!
- now you have an file iolog.tar.gz on your sdcard
Click to expand...
Click to collapse
hey bauner i gave it a go using your dft rom and recieve this with no log after following your steps...
Card is a 16gb class 10 A-Ram card.
error is supplied in the attached pic:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Don't know if it will help here is my log, using an SD RAM Desire HD build on class 4 Sandisk MicrosdCard 1 partition 32GB FAT 32
happyhallsy8 said:
hey bauner i gave it a go using your dft rom and recieve this with no log after following your steps...
Card is a 16gb class 10 A-Ram card.
error is supplied in the attached pic:
Click to expand...
Click to collapse
the problem is that the scipt can´t write to your sdcard
is your first partition fat32? can you access it from your phone? Was mass storage mode enbabled?
In adb shell you can type:
mount
and look at its output. you should see a line like this
/dev/block/vold/179:1 /mnt/sdcard vfat rw,........
if this line is present type
ls -l /mnt/sdcard
now you should see the directory listing from sdcard.
finally type
ls -l /sdcard
the output should be
..........sdcard -> /mnt/sdcard
vlad48 said:
Don't know if it will help here is my log, using an SD RAM Desire HD build on class 4 Sandisk MicrosdCard 1 partition 32GB FAT 32
Click to expand...
Click to collapse
thx for the log
what filesystem do you use in loopfile?
Hello everyone
I am using an apk from Google Play Store called "NFC Reader Writer" by Manjul Saini on a smarphone Galaxy J7 with android 8.1.0
I am trying to copy the above NFC card. Here is the data have been read:
-Serial number: aa:42:3d:d1
-Tehnologies: NfcA, MifareClassic, NdeFormatable
-SAK (hex): 0x08:00
-ATQA (hex): 0x04:00
-Default tranceive time out: 618ms
-Max Tranceive Length: 253 bytes-
-Mifare Classic type: Classic
-Mifare size: 1024 bytes
-Mifare sectors: 16
-Mifare blocks: 64
But when trying to copy I get an error message "No NDEF messages found". Any ideas about this? Is it possible the card being protected?
Thanks in advance