The maximum size allowed for a MMS payload is determined staticlly by the rom at:
Code:
system\customization\mms\xml\constants.xml
The sizes are thus (in bytes):
Code:
00: 614400
11: 614400
12: N/A
13: Unknown
14: 1048576
15: 614400
21: 307200
30: N/A
31: 614400
32: 614400
33: N/A
34: Unknown
(See: Dell Update Process -xda wiki for information on which region maps to which carrier)
The sizes are this stored staticly in a rom instead of dynamiclly loaded like the APNs. Increasing or decreasing the size allows you to ATTEMPT to upload a larger or smaller MMS payload. Weither or not the carrier allows larger is dependant on them.
Disclaimer:
I am not responsible for any charges or warnings from your carrier if you modify your max MMS size to an unsupported value.
Did you try it? If so, any success?
Sent from my Dell Streak using XDA App
Related
I notice SD cards are rated 60x 133x or greater. Will I notice a difference on my Blue Angel?
Is the BA USB interface version 2.0?
I'm torn between getting the Sandisk 1GB (with built in USB) or the new 2GB, a third option is the new Sandisk Extremee III (1GB) with superfast 20Mbps xfer.
I am curious t this as well.
I recently purchased a no-frills 2GB SD card from newegg that claimed to be 150x. When benchmark testing with PocketMechanic, I saw that my storage card only did 1.8x read / 0.8x write. However, the onboard storage benchmarked to be 2.9x read / 4.2x write. [Note: Both onboard Storage and SD Storage card were formatted before testing.]
I haven't done the research to find out if BA is USB 1.1 or 2.0, but I've noticed that a USB SD card reader is significantly faster than transfering files through the BA. It took 4 minutes to transfer 73MB for 193 files and 39 folders via windows explorer, or roughly 300K/s, where as I was able to transfer 1.5GB in 401 files and 59 folders in roughly the same time via USB SD card reader.
If the speed of the no-name card is in question, I confirmed the speed to be at least 5.5MB/s, by copying back 1.5GB in 401 files / 59 folders in 270 seconds via USB to SD card reader. Had this been one single contiguous file, the transfer rates would have been alot faster... I could have confirmed by copying a like-sized file to the media, but you'll have to take my word on this, as I've already spent quite some time satisfying my own curiousity to answer your question
See below for Pocket Mechanic details:
Details:
Card tested "Storage Card"
Min. read time: 0.25ms
Max read time: 18.00 ms
Avg. read time 1.87ms
Sector/block: variable 4-64
Min write time: 0.50ms
Max write time: 16.00 ms
Avg. write time: 4.02ms
Read/write ratio: 0.46
Sector size: 512 bytes
Start Sector: 0
End Sector: 3910656
Total Sectors read: 2504
Total data read: 1.00MB
Total read time: 4673 ms
Total sectors written: 2504
Total data written: 1.00MB
Total write time: 10057ms
Details:
Card tested "Storage"
Min. read time: 0.25ms
Max read time: 16.00 ms
Avg. read time 1.14ms
Sector/block: variable 4-64
Min write time: 0.50ms
Max write time: 9.25 ms
Avg. write time: 0.80ms
Read/write ratio: 1.43
Sector size: 512 bytes
Start Sector: 0
End Sector: 125488
Total Sectors read: 2504
Total data read: 1.00MB
Total read time: 2855 ms
Total sectors written: 2504
Total data written: 1.00MB
Total write time: 2001ms
Thanks, pity you ont have any other cards to compare too.
FYI, my curiousity got the best of me again, so I tested my no frill card's speed more thoroughly. According to SiSoft Sandra, my card is at least 55x to 65x at 64MB chunks, via USB reader. See below for full details.
I also performed my own test, where I copied a single contiguous 1.9GB file (1944973970 bytes) to and from my SD card via USB reader.
Read: 262.50 seconds, 7.4MB/sec, 40x (@ 176K/x) or 50x (@ 150K/x)
Write: 204.84 seconds, 9.4MB/sec, 53x (@ 176K/x) or 63x (@ 150K/x)
This is no where close to the 150X claimed speed, but this may be a limitation of my 2.33Ghz Centrino laptop's 5400RPM hdd? Really can't tell since I don't have another SD card to test with, nor do I have current plans to test on other hardware...
Hope this helps!
---------
SiSoftware Sandra
Benchmark Results
Combined Index : 1296 operation(s)/min
Endurance Factor : 9.2
512B Files Test : 1382 operation(s)/min
32kB Files Test : 1617 operation(s)/min
256kB Files Test : 1012 operation(s)/min
2MB Files Test : 124 operation(s)/min
64MB Files Test : 8 operation(s)/min
Results Interpretation : Higher index values are better.
Performance Test Status
Run ID : ALEX2 on Saturday, August 27, 2005 at 11:51:07 PM
SMP Test : No
Total Test Threads : 1
SMT Test : No
Dynamic MP/MT Load Balance : No
Processor Affinity : No
512B Files Test
Read Performance : 13831 operation(s)/min (115 kB/sec, 0x)
Write Performance : 494 operation(s)/min (4 kB/sec, 0x)
Delete Performance : 1358 operation(s)/min
File Fragments : 1.0
Combined Index : 1382 operation(s)/min
32kB Files Test
Read Performance : 7001 operation(s)/min (3734 kB/sec, 21x)
Write Performance : 653 operation(s)/min (348 kB/sec, 1x)
Delete Performance : 1366 operation(s)/min
File Fragments : 1.0
Combined Index : 1617 operation(s)/min
256kB Files Test
Read Performance : 1865 operation(s)/min (7957 kB/sec, 45x)
Write Performance : 507 operation(s)/min (2163 kB/sec, 12x)
Delete Performance : 1340 operation(s)/min
File Fragments : 1.0
Combined Index : 1012 operation(s)/min
2MB Files Test
Read Performance : 267 operation(s)/min (9114 kB/sec, 51x)
Write Performance : 52 operation(s)/min (1775 kB/sec, 10x)
Delete Performance : 937 operation(s)/min
File Fragments : 1.0
Combined Index : 124 operation(s)/min
64MB Files Test
Read Performance : 8 operation(s)/min (8738 kB/sec, 49x)
Write Performance : 6 operation(s)/min (6554 kB/sec, 37x)
Delete Performance : 555 operation(s)/min
File Fragments : 1.0
Combined Index : 8 operation(s)/min
Endurance Test Status
Operating System Disk Cache Used : No
Use Overlapped I/O : No
Test File Size : 32MB
Block Size : 512 byte(s)
File Fragments : 1
Endurance Benchmark Breakdown
Repeated Sector ReWrite : 333 kB/s
Sequential Sector Write : 332 kB/s
Random Sector Write : 25 kB/s
Drive
Total Size : 1.9GB
Free Space : 1.9GB, 100%
Cluster Size : 4kB
Performance Tips
Notice 5901 : 1x=176kB/s; As some device makers use 1x=150kB/s exercise caution when comparing measured vs. published ratings.
Notice 5008 : To change benchmarks, click Options.
Notice 5004 : Synthetic benchmark. May not tally with 'real-life' performance.
Notice 5006 : Only compare the results with ones obtained using the same version!
Notice 5207 : Consider using the File System Benchmark for non-Flash devices.
Notice 5900 : Endurance factor can only be used on the same type of device (SLC or MLC).
Tip 11 : Use the 'Switch Chart Type' button to switch between Detailed and Combined charts.
Tip 2 : Double-click tip or press Enter while a tip is selected for more information about the tip.
Have been trying to sim unlock my MT4G. I've tried using the gfree method here using multiple different ROMS, but keep getting the error message below:
Code:
# ./gfree -f
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.35.10-g225de41
New .modinfo section size: 204
Attempting to power cycle eMMC... Failed.
Module failed to load: No such file or directory
I haven't tried a really old kernel/ROM--not sure if that is still necessary. There were posts in the above thread that indicated that I could now use any ROM/kernel. FWIW, I'm using the new I guess "official" ROM. Before that, I tried the CM7 stable RC as well as the latest nightly.
Hello everyone, new user here from Montréal, Canada!
I have a question regarding the "boot" MTD device on this cheap gigabyte/proscan tablet (model: plt1066g) - When i try to write what looks like a perfectly valid boot file to the boot partition, the device freezes on the OEM (proscan) boot logo, just after adjusting the brightness. It never gets to the green trashcan/r2d2 that flashes for a second, or the android boot animation.
If i re-flash the original image that i dumped from the MTD device, it works fine, so i know it's not a problem with the flashing process or the flashing tool i'm using.
The aforementioned original boot image consists of the following parts at the following offsets:
Code:
10 0xA LZMA compressed data, properties: 0x2E, dictionary size: 8388608 bytes, uncompressed size: 259087888 bytes
2048 0x800 uImage header, header size: 64 bytes, header CRC: 0xBA042549, created: Fri Aug 1 03:43:38 2014, image size: 3027415 bytes, Data Address: 0x80008000, Entry Point: 0x80008000, data CRC: 0x74A1309A, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: lzma, image name: "Linux-3.0.8"
3031040 0x2E4000 gzip compressed data, was "ramdisk.cpio", from NTFS filesystem (NT), last modified: Fri Aug 1 04:24:34 2014, max compression
I simply extracted the cpio archive, modified the init.rc script in this archive, then re-generated the archive and wrote it at the correct offset in my new copy of the boot image. This new boot image now contains:
Code:
10 0xA LZMA compressed data, properties: 0x2E, dictionary size: 8388608 bytes, uncompressed size: 259087888 bytes
2048 0x800 uImage header, header size: 64 bytes, header CRC: 0xBA042549, created: Fri Aug 1 03:43:38 2014, image size: 3027415 bytes, Data Address: 0x80008000, Entry Point: 0x80008000, data CRC: 0x74A1309A, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: lzma, image name: "Linux-3.0.8"
3031040 0x2E4000 gzip compressed data, was "ramdisk.cpio", from Unix, last modified: Wed Sep 16 14:55:00 2015, max compression
.... so it's not a problem with the image file, or with the cpio archive contained in the file (i checked that as well), or - at least i think - not a problem with the added lines in the init.rc file. Which leads me to suspect that the only possibiliity is that there's somehow a checksum or some other kind of hash check being done on the partition - for example in that small unused section at the beginning of the partition/image. If that's the case, is there some documentation about the process, or at least some ready-made tool that would generate the proper hash check?
Thanks very much for any assistance.
/* edit */ Oh, i forgot to mention that this device is running Android 4.1.1.
/* edit2 */ Also thought it might be a good idea to share the actual resulting image. Here it is: (sorry, message board is preventing me from attaching/linking to files :/ )
Most shipping devices have locked bootloaders that allow only booting signed kernels. Is your bootloader unlocked?
I still don't know the answer to my original question, but using a utility called 'mkbootimg' instead of manually assembling the image myself, solved the problem. There doesn't seem to be any (other) locking mechanism on the boot loader of this device.
Thanks for your reply!
Hi,
I have searched the forums and still haven't found any useful information.
I've been trying to edit a ubifs image (system.img) for a generic mediatek tablet.
These are the many things I have tried:
1) Edit the boot.img so that ro.secure=0 etc to see if I can get root. Unfortunately selinux is enabled and I don't even have busybox on the system (something called toolbox)
2) Work out what nand flash is being used (in my case its - SanDisk SDTNRGAMA 64G 3.3V 8-bit). And emulate the nand by using nandsim on a linux computer, but it causes a segmentation fault:
Code:
sudo modprobe nanDsim id_bytes=0x45,0xde,0x94,0x93,0x76,0x50 cache_file=./test.img
Note - I have included a spelling mistake (nanDsim should be nandsim) because I dont' want anyone to just cut and paste this command - it causes a segmentation fault on Ubuntu and Debian and I have found that if you are running on an ssd system it will hard lock your pc! (You have been warned).
3) Use ubireader (github.com/jrspruitt/ubi_reader).
Code:
$ ubireader_display_info ./system.img
UBI File
---------------------
Min I/O: 16384
LEB Size: 4161536
PEB Size: 4194304
Total Block Count: 122
Data Block Count: 120
Layout Block Count: 2
Internal Volume Block Count: 0
Unknown Block Count: 0
First UBI PEB Number: 0
Image: 1101756791
---------------------
Image Sequence Num: 1101756791
Volume Name:system
PEB Range: 0 - 121
Volume: system
---------------------
Vol ID: 0
Name: system
Block Count: 120
Volume Record
---------------------
alignment: 1
crc: 3336263623
data_pad: 0
errors:
flags: autoresize
name: system
name_len: 6
padding:
rec_index: 0
reserved_pebs: 248
upd_marker: 0
vol_type: dynamic
but when I run 'ubireader_extract_files' I get all the files, but they are all corrupted.
I'm currently trying to use the information in the ubireader_display_info to create a blank ubifs image and using 'linux dd' to try and read the image that I have.
Has anyone got any tips on how to progress, your help and advice would be appreciated.
Hi all,
For some reason I want to modify the bootloader on my device(Lenovo Zuk Z2 plus, which has SnapDragon 820, MSM8996). I have research a little bit and got a snippet of assembly code that I believe appears in the bootloader, and I hope to replace.
So I believe the xbl.elf file in the stock ROM, which is to be flashed by QPST, is the bootloader I hope to hack. My plan:
1. Interpret the file xbl.elf
2. find the snippet of code I hope to replace
3. replace the snippet of binary with some cooler binary.
So here is the result of `readelf -a xbl.elf`:
Code:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: AArch64
Version: 0x1
Entry point address: 0x6213f10
Start of program headers: 64 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 17
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
There are no sections in this file.
There are no sections to group in this file.
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NULL 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000000003f8 0x0000000000000000 0
NULL 0x0000000000001000 0x0000000085eec000 0x0000000085eec000
0x0000000000001b48 0x0000000000002000 1000
LOAD 0x0000000000003000 0x0000000006208000 0x0000000006208000
0x00000000000567b4 0x00000000000567b4 R E 10000
LOAD 0x00000000000597c0 0x000000000625f000 0x000000000625f000
0x0000000000009a58 0x0000000000009a58 RW 10000
LOAD 0x0000000000063220 0x000000000626a000 0x000000000626a000
0x0000000000000000 0x00000000000052a8 RW 10000
LOAD 0x0000000000063220 0x0000000085e00000 0x0000000085e00000
0x0000000000000000 0x0000000000024da0 RW 10000
LOAD 0x0000000000063220 0x0000000006680000 0x0000000006680000
0x00000000000029d0 0x00000000000029d0 R E 10000
LOAD 0x0000000000065bf0 0x0000000006683000 0x0000000006683000
0x0000000000000694 0x0000000000000694 RW 10000
LOAD 0x0000000000066290 0x000000000021e000 0x000000000021e000
0x0000000000005e54 0x0000000000005e54 R E 10000
LOAD 0x000000000006c0f0 0x00000000066a2000 0x00000000066a2000
0x0000000000000000 0x0000000000012400 RW 10000
LOAD 0x000000000006c0f0 0x0000000085e80000 0x0000000085e80000
0x00000000000282ee 0x00000000000282ee R E 10000
LOAD 0x00000000000943e0 0x0000000085ec0000 0x0000000085ec0000
0x000000000002b9a0 0x000000000002b9a0 RW 10000
LOAD 0x00000000000bfd80 0x0000000085eb0000 0x0000000085eb0000
0x0000000000000000 0x00000000000099e8 RW 10000
LOAD 0x00000000000bfd80 0x0000000080200000 0x0000000080200000
0x00000000000f0000 0x00000000000f0000 RWE 1000
LOAD 0x00000000001afd80 0x0000000000207000 0x0000000000207000
0x000000000000ebe1 0x000000000000ebe1 R E 10000
LOAD 0x00000000001be970 0x0000000000217800 0x0000000000217800
0x00000000000004c8 0x00000000000004c8 RW 10000
LOAD 0x00000000001bee40 0x0000000000219800 0x0000000000219800
0x0000000000000000 0x00000000000001d0 RW 10000
There is no dynamic section in this file.
There are no relocations in this file.
The decoding of unwind sections for machine type AArch64 is not currently supported.
Dynamic symbol information is not available for displaying symbols.
No version information found in this file.
So as you can see, this elf file is quite uncommon. Anyone has any idea how to interpret this file? Thanks!
Solved
Nevermind, I simply regard this file as binary and disemble it:
aarch64-linux-gnu-objdump -b binary -D xbl.elf -maarch64
And the assembly is crystally clear!