[Q] Question about amss.bin - Bada Software and Hacking General

Hello people,
Are there any tools for viewing and editing the amss.bin?

HEX Editor...
IDA...
Brain.
Best Regards

adfree said:
HEX Editor...
IDA...
Brain.
Best Regards
Click to expand...
Click to collapse
with revskill i got this with amss.bin
#define UNLOADED_FILE 1
#include <idc.idc>
static main() {
MakeName(0x00079B70, "Memcmp");
MakeName(0x00062160, "Memcpy");
MakeName(0x0022E924, "Memcpy");
MakeName(0x0006216B, "Memcpy_Generic");
MakeName(0x0022E92F, "Memcpy_Generic");
MakeName(0x000621D0, "__rt_udiv");
MakeName(0x00079F8C, "__rt_udiv");
MakeName(0x00062334, "strlen");
MakeName(0x0007A2C4, "strlen");
MakeName(0x00070DB2, "diag_sp");
MakeName(0x00062298, "strcmp");
MakeName(0x0007A1D8, "strcmp");
MakeName(0x0007A360, "strncpy");
MakeName(0x00072502, "diag_pkt");
MakeName(0x00062F00, "__rt_div0");
MakeName(0x0007D324, "__rt_div0");
MakeName(0x00062F10, "__32__rt_raise");
MakeName(0x0007F1F8, "__32__rt_raise");
MakeName(0x00ACC3A8, "rex_int_lock_32");
MakeName(0x00072330, "subsys_getid");
MakeName(0x0007A548, "vsprintf");
MakeName(0x00062004, "MemClr");
MakeName(0x0022E7C8, "MemClr");
MakeName(0x000725CC, "diag_subsystem");
MakeName(0x0006EC72, "diag_hdlr");
MakeName(0x000726D2, "diag_hdlr");
MakeName(0x00083D86, "diag_hdlr");
MakeName(0x00085432, "diag_hdlr");
}
What about it ?

@Tigrouzen, no segment found at 0x00079B70 etc
amss it's regular elf with a bunch of segments
Code:
Name : LOAD
Start : 0x001E7000
End : 0x001EE000
Length: 0x00007000
----------------------
Name : LOAD
Start : 0x001F0000
End : 0x001F1000
Length: 0x00001000
----------------------
Name : LOAD
Start : 0x001F2000
End : 0x005D8000
Length: 0x003E6000
----------------------
Name : LOAD
Start : 0x005D8000
End : 0x00CDB000
Length: 0x00703000
----------------------
Name : LOAD
Start : 0x00CDB000
End : 0x00D11000
Length: 0x00036000
----------------------
Name : LOAD
Start : 0x00D11000
End : 0x00DAF000
Length: 0x0009E000
----------------------
Name : LOAD
Start : 0x00DAF000
End : 0x00DB9000
Length: 0x0000A000
----------------------
Name : LOAD
Start : 0x00DB9000
End : 0x00E9B000
Length: 0x000E2000
----------------------
Name : LOAD
Start : 0x00E9C000
End : 0x01BF9000
Length: 0x00D5D000
----------------------
Name : LOAD
Start : 0x01BF9000
End : 0x01D05000
Length: 0x0010C000
----------------------
Name : LOAD
Start : 0x01FF0000
End : 0x01FF006C
Length: 0x0000006C
----------------------
Name : LOAD
Start : 0xB0000000
End : 0xB0010CE7
Length: 0x00010CE7
----------------------
Name : LOAD
Start : 0xB0040000
End : 0xB0057000
Length: 0x00017000
----------------------
Name : LOAD
Start : 0xB0100000
End : 0xB0107207
Length: 0x00007207
----------------------
Name : LOAD
Start : 0xB0140000
End : 0xB01401B8
Length: 0x000001B8
----------------------
Name : LOAD
Start : 0xB0200000
End : 0xB0208CF3
Length: 0x00008CF3
----------------------
Name : LOAD
Start : 0xB0240000
End : 0xB024028C
Length: 0x0000028C
----------------------
Name : LOAD
Start : 0xB0400000
End : 0xB040DBE8
Length: 0x0000DBE8
----------------------
Name : LOAD
Start : 0xB0600000
End : 0xB0602000
Length: 0x00002000
----------------------
Name : LOAD
Start : 0xB0602000
End : 0xB0604000
Length: 0x00002000
----------------------
Name : LOAD
Start : 0xF0000000
End : 0xF001F878
Length: 0x0001F878
----------------------
Name : LOAD
Start : 0xF0020000
End : 0xF0026000
Length: 0x00006000
load amss.bin with TriX, dump decoded stage (elf format) and analyze with disassembler (e.g. IDA)

Ok guys i extract certificate from Amss S8530 XEJL2, bootloader segments full info fsbl sbl...
Also i can dump complete NAND and find segment and algorith for RC1 too
This is appscompressed.bin algorythme
0x01ca7750 RIPEMD128+160+MD4
0x01ca7750 SEAL+MD4 key
appcomp hash :
SHA1 : EB55C6690ACAF40BB2F845313F58BFE9C3BC529D
SHA224 : AAC3E2B65CC9F33BB7EDDA3DEB541CA9E8919422CC179B4D2B49F39BAE008F00
SHA256 : 580D3DB21E41A9FE588AE544266040FABA8AF044E739971E77F2B1272323D0B6
SHA256-HTC : A44BC029D7F952750003D9695ED7B464E446D34EEF5BD9665487E4C2BF81F669
MD4 : B3BD8310FF2C4C05E2044FD491814792
MD5 : 7220779D1094C5F7789094DC75BA4E9E
CRC16 (0x1189) : F4EA
CRC30 (Block: 0x1000, Page: 0x200) : 0BD214AA
CRC30 (Block: 0x2000, Page: 0x400) : 0A28A17A
CRC32 (0xEDB88320) : 313F4EF2
CRC32 (0x04C11DB7) : 90B01704
CRC32 HTC (0xEDB88320) : B55B60A7
ECC Reed Solomon (parity 10) : 43702DA1FDAC4DB2023B
ECC BCH Micron 3 byte : 818144
ECC Hamming Toshiba (8 bit - 0x200 bytes) : C00FC3
ECC Hamming (8 bit - 0x200 bytes) : FF3CF3
ECC Hamming (16 bit - 0x200 bytes) : 3FCFFC
Amss algo :
0x0007fce0 CRC-16 norm
0x0007fee0 CRC-16 inv
0x0007f8e0 CRC-30
0x0007eb50 CRC30 Function
0x00b66194 CRC-32
0x00b66394 CRC32 Function
0x000800e0 CRC-32 Xilinx
0x0007eb58 CRC32 Xilinx Function
0x000800e4 CRC32 Xilinx Function
0x00c3c490 DES RAW Spbox
0x00c39381 RSA PKCS SHA1/RIPEND Digest
0x00c39390 MD2 S
0x00463548 SHA2 table
0x008fcc88 SHA2 table
0x00b6eb14 ZDeflate
0x0041a28c SHA1+MD4+MD5 init
0x008fcb08 SHA1+MD4+MD5 init
0x00c3d7f8 SHA1+MD4+MD5 init
0x0041a29c SHA1+MD4+MD5 key1
0x008fcb18 SHA1+MD4+MD5 key1
0x00c3d808 SHA1+MD4+MD5 key1
0x001a9844 SHA1+MD4+MD5 key2
0x0041ac1c SHA1+MD4+MD5 key2
0x008fcb1c SHA1+MD4+MD5 key2
0x001a9848 SHA1+MD4+MD5 key3
0x0041ac20 SHA1+MD4+MD5 key3
0x008fcb20 SHA1+MD4+MD5 key3
0x00463648 SHA2 init table
0x008fcd88 SHA2 init table
0x00c3d80c SHA2 init table
0x0046364c SHA2 init table
0x008fcd8c SHA2 init table
0x00c3d810 SHA2 init table
0x00419980 RIPEMD128+160+MD4
0x008fcaf8 RIPEMD128+160+MD4
0x00bdcca0 RIPEMD128+160+MD4
0x001a9844 MD5
0x0041ac1c MD5
0x008fcb1c MD5
0x00419980 SEAL+MD4 key
0x008fcaf8 SEAL+MD4 key
0x00bdcca0 SEAL+MD4 key
0x004fc7af HTC PUBLIC KEY
E9079DBB2452104990982132470BA20B7C795D1B4690B718B62FCD38D71D4E458FAF320374B89D5236C79BD57D2BA2D3508A4A605B0D48CB8CA5478BFE4D7D32AB0AE072BC367A9615F002D5023A617B422FEC1EF8DAD772D75E9C4F06EF624B864699A3F080D1B8E192B921D159852B2DC798F752B4F1FA529FF123D9963F73
0x00708134 Sober 128
0x00c3cd90 Sober 128 SBox
Possible algos little endian: 45
0x00315f6c AES te
Possible algos big endian: 1
Amss hash :
SHA1 : C59C5785E823E5E1CA9BE05DB6F55F8C8AC1BBA3
SHA224 : 5F50CED13C1204068E443919706B53D866271DAB1CFB5A9CB07A953CAE008F00
SHA256 : D86C7634FE07806D3B87701EC7F72F25DAAFAC7C40CA1D370C1ABA5840C091C0
SHA256-HTC : 120F70AECE78B8DCF69DCD79F020AB00AE17572123BA21274D6F6EE280774A09
MD4 : 7703DF5B1074392D4B91ECA23BAC9D92
MD5 : 22197F8AAD6A2CB4394E1B4E63EB843C
CRC16 (0x1189) : FAC5
CRC30 (Block: 0x1000, Page: 0x200) : 311AE4C7
CRC30 (Block: 0x2000, Page: 0x400) : 295DFC29
CRC32 (0xEDB88320) : 8DB21A34
CRC32 (0x04C11DB7) : 7B94B6A4
CRC32 HTC (0xEDB88320) : 08450BBC
ECC Reed Solomon (parity 10) : A04D69B134A126F3FD15
ECC BCH Micron 3 byte : 000000
ECC Hamming Toshiba (8 bit - 0x200 bytes) : FFFFFF
ECC Hamming (8 bit - 0x200 bytes) : FFFFFF
ECC Hamming (16 bit - 0x200 bytes) : FFFFFF
Amms certificat :
https://rapidshare.com/files/3061245812/1.cer

Well, the main idea was ..., to get some tools with which the amss.bin for bada v1.2 and v2 can be modified to work for the American/Australian version of the wave. Looks like there are some hardware differences and this file is containing information needed for the RF module.

Looks like there are some hardware differences and this file is containing information needed for the RF module
Click to expand...
Click to collapse
No idea if Hardware differences, but I'm pretty sure there are different Config/Calibration data...
Check out NV items... AMSS + NV items = Qualcomm related part...
http://www.samsunguniverse.com/forum/s8500-can-work-with-qualcomm-tools-t199.html
You could take an look on FCC documents for maybe Hardware check...
Best Regards

I think gambal refers to UMTS bands, Europe is different than in America.
UMTS bands in America are 850 - 1900
UMTS bands in Europe are 2100
bada 1.2 and above only works with Euro bands (these updates hasn't oficially released in America), so as we know the file "amss.bin" contains the parameters that define which bands to work, would be good to try to edit the information to compile a new "amss.bin" to work with American bands ..
Many Americans would be happy!

...would be good to try to edit the information to compile a new "amss.bin" to work with American bands ...
Click to expand...
Click to collapse
But you are really sure that not NV items differ?
Maybe easier to compare NV items...
Best Regards

You mean to compare amss NV items from a 1.0 American firmware and another 1.2 European firmware?
I was import to a .Qcn file a list of NV items of my mobile (bada 1.0 american), i will compare with another one of 1.2.
It's posible to create more NV items if is necesary?

sorry for double post.
i've compared NV items of my phone, first with a 1.0 american firmware then with a 1.2 European firmware..
EDIT: thought that there were no differences because the file size was identical, but looking more attentively i find some, i will continue researching,

You tried QPST or which Tool?
And are sure there are no differences?
I have 2x S8500... with QPST difference 10 NV items + one S8500 has 10 more
Content not checked... too lazy at this time.
Best Regards
Edit 1.
File Summary:
Phone Model: 19 [QSC6270/QSC6240], Configuration Name: default, Total NV Item Count: 305
Click to expand...
Click to collapse
File Summary:
Phone Model: 19 [QSC6270/QSC6240], Configuration Name: default, Total NV Item Count: 319
Click to expand...
Click to collapse
And these are only the "official" NV items... and not the hidden one...
Example...
Code:
NV item: [B]2608[/B] [NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I], index 0
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 0: 12 3d fc ff 9c 3c fc ff 26 3c fc ff b0 3b fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 1: 34 3b fc ff af 3a fc ff 2a 3a fc ff a6 39 fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 2: 22 39 fc ff 9f 38 fc ff 0c 38 fc ff 65 37 fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 3: be 36 fc ff 18 36 fc ff 73 35 fc ff ce 34 fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 4: 2a 34 fc ff 87 33 fc ff e5 32 fc ff 43 32 fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 5: a2 31 fc ff 01 31 fc ff 61 30 fc ff c2 2f fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 6: 23 2f fc ff 85 2e fc ff 85 2e fc ff 85 2e fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 7: 85 2e fc ff 85 2e fc ff 85 2e fc ff 85 2e fc ff

sorry for my english, I mean to say that i find some differences..
between 2 firmwares, I find 40 differents NV items using "RF NV items Manager" program.
Example:
European 1.2 Firm:
Code:
NV item: 5059 [NV_WCDMA_2100_TX_LIN_MASTER_0_ENH_I], index 0
NV item: 5061 [NV_WCDMA_900_TX_PDM_LIN_0_ENH_I], index 0
American 1.0 Firm:
Code:
NV item: 5064 [NV_WCDMA_1900_TX_PDM_LIN_0_ENH_I], index 0
NV item: 5060 [NV_WCDMA_800_TX_PDM_LIN_0_ENH_I], index 0
(it's look like these items manage the umts network)
This are 2 items of 40 that I find.. So, I imported all 40 1.0 American Firmware Nv Items to the 1.2 Euro Firmwared Phone, (using previous modified .QCN file) then, i restart the device, but nothing happen, still no find UMTS network... But i want believe that we are close to find the solution
If I use PSAS to Display the new added NV items, these appear as "inactive item" and those already on the phone appears lile "bad parameter"
not know what else I can try...

Even if NV items count is different. Dump of NV area will be always the same in size. Area in oneNAND reserved for NV data is constant, and in most it's just empty space, filled with zeros.

Is it possible to dump whole NV items list using QPST? Can you guys do that and send dumps to me?
If not please search for following NV items and send me values you get (if you get any)
Int id 556
Int id 5
Int id 7
Int id 1403
String id 254
String id 387
String id 388
String id 256
String id 197
I want to prove some theory just taken from Bada kernel and need few different values to compare. These should contain Timezone, Locale and SimBlock settings. (If these NV items are even available)
Please send me PMs with dumps if you get any. Thanks in advance.

Tell me when you are ready "amms.bin" to "bada 2.0" so I can put it on my phone. I'm from Argentina. Thank you very much!

Rebellos said:
Int id 556
Int id 5
Int id 7
Int id 1403
Click to expand...
Click to collapse
With "PSAS" display "Inactive Item", and with "RV NV item manager" i don't these id's..
@adfree
Hey, if I wrote in phone (with "RV NV item manager") some NV items, is not take any effect... does exist another step to "activate" these items or some? maybe in Stune have to add any parameter? or maybe the "QPST Service program" tool..
I have fear of breaking the handset really... I just wan't to calibrate the UMTS bands, need these:
WCDMA_II_PCS_1900
WCDMA_V_850

http://forum.xda-developers.com/showpost.php?p=12436452&postcount=1
Other way to access NV items.
Now you can backup with sTune for instance... folders:
Code:
[B]NV
nvm[/B]
EXTREME Caution!
Some IDs are protected... so you can maybe write/activate, but not easily remove change = brick...
Best Regards

a little question..
there is a firmware of S8530 which has bada 1.2 and 850/900/2100Mhz 3g bands capable... there are firmwares prepared for Brazil and Australia.
it's posible to flash that amss.bin in a S8500 with bada 1.2?
I tried this, but the bootloader says "error erase amms"

amss.bin in a S8500 with bada 1.2?
Click to expand...
Click to collapse
If I remember correct, then yes...
Maybe not all combinations...
BUT check Multiloader ... adresses are different...
So you have to edit...
Later more.
Maybe give Link to this S8530 Firmware, so I can take an look or try for you...
Best Regards

Related

Can`t extract files from imgfs from HP iPaq 1950 ROM

Hi, all! Please, help me to solve my problem
Yesterday i tried to build custom ROM image for my PDA and failed .
I made following steps:
1. I made a backup of the existing ROM using mtty and SD card. The result was the 29mb raw file
2. i downloaded the last ROM update from the HP site, extracted it and obtained the ceos.nbf file.
3. Next, i tried to use prepare_imgfs and viewimgfs utilities whith both files.
4. After using prepare_imgfs i got, as expected, the imgfs_raw_data.bin file
5. But when i used viewimgfs, it couldn`t find any data in that file! Here is it's output:
Code:
guidBootSignature: F8 AC 2C 9D E3 D4 2B 4D BD 30 91 6E D8 4F 31 DC
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 00013620
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
Address: 00000200, dwBlockSignature: 00001D20
dwNextHeaderBlock: FFFBFFFF (size: FFFBFDFF)
Header type: 2F5314CE, Addr: 00000208
Unknown header type, FS_DATA_TABLE??
and more messages like that.
Can anyone tell me, where is the problem?
PS sorry for terrible English
stanru1 said:
Hi, all! Please, help me to solve my problem
Yesterday i tried to build custom ROM image for my PDA and failed .
I made following steps:
1. I made a backup of the existing ROM using mtty and SD card. The result was the 29mb raw file
2. i downloaded the last ROM update from the HP site, extracted it and obtained the ceos.nbf file.
3. Next, i tried to use prepare_imgfs and viewimgfs utilities whith both files.
4. After using prepare_imgfs i got, as expected, the imgfs_raw_data.bin file
5. But when i used viewimgfs, it couldn`t find any data in that file! Here is it's output:
Code:
guidBootSignature: F8 AC 2C 9D E3 D4 2B 4D BD 30 91 6E D8 4F 31 DC
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 00013620
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
Address: 00000200, dwBlockSignature: 00001D20
dwNextHeaderBlock: FFFBFFFF (size: FFFBFDFF)
Header type: 2F5314CE, Addr: 00000208
Unknown header type, FS_DATA_TABLE??
and more messages like that.
Can anyone tell me, where is the problem?
PS sorry for terrible English
Click to expand...
Click to collapse
i would like to know an answer for this too. thanks
I found solution to extract files, but i couldn't find out how to pack it back...
To unpack files, you need:
1. the Perl interpreter
2. script, which can be found on http://forum.wce.by/viewtopic.php?p=78923#78923
3. You must replace $A and $S variables with your values:
$A is the address of the beginning of the imgfs block. It can be found using WinHex and F8AC2C9DE3D42B4DBD30916ED84F31DC signature. $S is size of imgfs block. It can be found with signature E9FDFF. You must find the table of partitions, and take 4 bytes as it's shown on the screenshot, in the reverse order. (00 C0 BD 00 -> 00BDC000)
For example, for iPaq1950 rom, taken from HP update, values are:
$I = "CEOS.nbf";
$O = "bigbrother.bin";
$A = 0x003BB55A;
$S = 0x0000BDC0;
After Perl script ends it's work you can use imgfsToDump or viewimgfs tools.
For this solution HUGE thanks to Gvr.
stanru1 said:
I found solution to extract files, but i couldn't find out how to pack it back...
To unpack files, you need:
1. the Perl interpreter
2. script, which can be found on http://forum.wce.by/viewtopic.php?p=78923#78923
3. You must replace $A and $S variables with your values:
$A is the address of the beginning of the imgfs block. It can be found using WinHex and F8AC2C9DE3D42B4DBD30916ED84F31DC signature. $S is size of imgfs block. It can be found with signature E9FDFF. You must find the table of partitions, and take 4 bytes as it's shown on the screenshot, in the reverse order. (00 C0 BD 00 -> 00BDC000)
For example, for iPaq1950 rom, taken from HP update, values are:
$I = "CEOS.nbf";
$O = "bigbrother.bin";
$A = 0x003BB55A;
$S = 0x0000BDC0;
After Perl script ends it's work you can use imgfsToDump or viewimgfs tools.
For this solution HUGE thanks to Gvr.
Click to expand...
Click to collapse
Very nice thanks.
If you find a way to repack it, it would be even better. I actually want to use this method for the hp1930. My problem is that there are no official updates for this model, so I have no shipped roms. Only a sd image dump.
What type of image is the sd dump? dnf or .bin (raw) ?
I think, it`s a raw dump. In any case, imgfs is the same on both images.
stanru1 said:
I think, it`s a raw dump. In any case, imgfs is the same on both images.
Click to expand...
Click to collapse
thanks again
any idea on how to get start address and size from a sd image? I can't find those signatures in the dump
thanks
The signatures may differ in case of the specific image. If you whant, i could look at your file, if you upload your rom into the Rapidshare or the same file-uploading service and give me the link
stanru1 said:
The signatures may differ in case of the specific image. If you whant, i could look at your file, if you upload your rom into the Rapidshare or the same file-uploading service and give me the link
Click to expand...
Click to collapse
thanks man,
I'm uploading to rapidshare right now.
the image was created using a 64mb sd so the image size might be a bit longer
edit :
this is the link: http://rapidshare.com/files/25438977/1930.rar.html
any updates on how to modify a sd image?

Help in HEX convert need

Hi.
i need a litle help in hex convert.
in Bepe threads i fond this.
- nb file: 0x000001F5: short value + 0x48 (e.g: 0xA7+0x48=0xEF)
- nb file: 0x000001FB: short value + 0x48
A7 00 + 0x48 = EF 00
DB 05 + 0x48 = 23 06
i dont know if that is correct or not but if yes wath the value for this?
A2 01 + 0x48 = ??????
Thx and regards
I think you are not adding the columns correctly here. See your examples below along with a base 10 (the way we normally count) example (notice the numbers are lined up just as you would if you were adding base 10 numbers, from the least significant column to the most significant column, right to left)
A7 00 DB 05 100 (base 10 example)
+ 48 + 48 + 10
-------- ------ ----
A7 48 DB 4D 110
A7 + 48 does add to EF, but that is leaving out 2 entire orders of significance at the end of the A7 00 number.
So, the answer to your next question then would be:
A2 01
+ 48
------
A2 49
Also, just FYI here, the Calculator program that comes w/ Windows based computers will do Hex arithmetic for you. To get it to hex mode, start the Calculator, click on the View menu and choose Scientific. The calculator will then change it's view so that you can do Hex, Decimal (base 10), Octal or Binary arithmetic.
Hope that makes sense. If not, ask and I'll try to do a better job explaining.

DSM file structure uderstanding

Please sorry me if it is wrong place for my post and please move it to correct place.
Hi guys. I'm trying to discover dsm files structure and I've got some troubles. So i need an advance and hope to find somebody who can wll help me with it.
As i uderstand dsm header look like this:
typedef struct _DeviceManifestHeader
{
const DWORD dwStructSize; // Size of this structure header
const DWORD dwUnknown1; // Unknown for me
const DWORD dwUnknown2; // Unknown for me
const DWORD dwUnknown3; // Unknown for me
const DWORD dwUnknown4; // Unknown for me
const DWORD dwNameLength; // length of filename in bytes.
const DWORD dwNameOffset; // offset to name of package
const DWORD dwUncnown5Count; // Count of unknown entries.
const DWORD dwUncnown5Offset; // Offset to uncnown entries.
const DWORD dwShadowCount; // possible dependent GUID list?.
const DWORD dwShadowOffset; //offset to dependent GUIDs.
const DWORD dwFileCount; // How many files in this manifest.
const DWORD dwFileListOffset; // Offset to the first FileEntry.
const DWORD cbCERTData; // Possible certificate data?
const DWORD dwCERTDataOffset; // offset to the certificate data.
const GUID guidPackage; // GUID of this package same as file name
const GUID2 guidPackage; // possible another guid?
}DeviceManifestHeader, *PDeviceManifestHeader;
typedef struct _FileEntry {
const DWORD dwNameLength;
const DWORD dwFlags;
const DWORD dwOffset;
const DWORD dwBase;
cons DWORD FileSize;
}FILEENTRY,*PFILEENTRY;
So it will be great if somebody will help me with my unknows and manly provide any information about Certificate structure.
Thanks in advance and sorry for my english.
According to my analysis :
TDSMHeader = record
dwStructSize : LongInt; // Size of this structure (in bytes) for versioning
Unknown_1 : LongInt; // 02 00 00 00
Unknown_2 : LongInt; // C2 01 00 00
Unknown_3 : LongInt; // F5 01 00 00
Unknown_4 : LongInt; // 00 00 00 00
dwNameLength : LongInt; // length of filename in bytes.
dwNameOffset : LongInt; // offset to Friendly name of package
dwDependentCount : LongInt; // How many entries in Dependent GUID list.
dwDependentOffset : LongInt; // How many bytes from the front of the file are the dependent GUID structs.
dwShadowCount : LongInt; // How many entries in shadow GUID list.
dwShadowOffset : LongInt; // How many bytes from front of file is the array of shadowed package GUIDs.
dwFileCount : LongInt; // How many files are there listed in this manifest.
dwFileListOffset : LongInt; // How many bytes from the front of file to the first FileEntry.
dwCERTDataLength : LongInt; // number of bytes of digital certificate data
dwCERTDataOffset : LongInt; // How many bytes from the front of file to the certificate data.
Unknown_5 : LongInt; // 05 00 01 00
Unknown_6 : LongInt; // D0 07 FF 39
Unknown_7 : LongInt; // 00 00 00 00
Unknown_8 : LongInt; // 00 00 00 00
Unknown_9 : LongInt; // 05 00 01 00
Unknown_A : LongInt; // D0 07 FF 39
guidPackage1 : TGUID; // GUID of this package}
guidPackage2 : TGUID; // Second GUID ?}
end;
TFileEntry = record
dwNameLength : LongInt;
dwFlags : LongInt;
dwNameOffset : LongInt;
FEUnknown : LongInt;
dwFileSize : LongInt;
end;
TDependentEntry = record
size : LongInt;
version : LongInt;
DEUnknown : LongInt;
guid : TGUID;
end;
I'm developed tool named DSMBuilder (http://forum.xda-developers.com/showthread.php?t=412272) that read and write DSM files and changed this attributes, certificates and rebuild file list.
dwStructSize is currently filled with the value 0x74 (116) and the structures of DSMHeader currently available on the Internet is not of this size
I'm a pascal developer's. In the future, I try to express as a C/C++ programmer.
thank you for your answer.
anmendes said:
According to my analysis :
dwCERTDataLength : LongInt; // number of bytes of digital certificate data
dwCERTDataOffset : LongInt; // How many bytes from the front of file to the certificate data.
Click to expand...
Click to collapse
As i understand CERTData that start from CERTDataOffset and contain CERTDataLength bytes is some kind of structure like dsmheader but i don't know it's format.
i mean:
CERTData = record
SomeThing : SomeType;
e.t.c.
end;
So while you developing DSMBuilder maybe you discover format of this CERTData structure if you did can you share it?
I've done a couple of tools (dsmbuild and dsminfo) which hopefully will be of some help for you:
http://code.google.com/p/htc-flasher/source/browse/#svn/trunk/RomKitchen
Files: dsm.h, dsminfo.c, dsmbuild.c
pof said:
I've done a couple of tools (dsmbuild and dsminfo) which hopefully will be of some help for you:
http://code.google.com/p/htc-flasher/source/browse/#svn/trunk/RomKitchen
Files: dsm.h, dsminfo.c, dsmbuild.c
Click to expand...
Click to collapse
thanks!
I will read very carefully their sources and update my tool, so you're done, put the sources here.
My mind and fully understand the structure of the file from DSM and also build new tools to manipulate roms or just for fun and curiosity.
ksandr said:
thank you for your answer.
As i understand CERTData that start from CERTDataOffset and contain CERTDataLength bytes is some kind of structure like dsmheader but i don't know it's format.
i mean:
CERTData = record
SomeThing : SomeType;
e.t.c.
end;
So while you developing DSMBuilder maybe you discover format of this CERTData structure if you did can you share it?
Click to expand...
Click to collapse
I do not know the structure of the certificates, but Windows Xp can read the files, then I believe that is the standard format for certificates (*. CER)
anmendes said:
I believe that is the standard format for certificates (*. CER)
Click to expand...
Click to collapse
Yes, the certificates use "cer" format.
Very thanks guys for your answers it's really helps me!
will study cer file format.
here one more question: in dsmheader there are two guids one same as file name and what is the other guid?
ksandr said:
Very thanks guys for your answers it's really helps me!
will study cer file format.
here one more question: in dsmheader there are two guids one same as file name and what is the other guid?
Click to expand...
Click to collapse
new version of my DMHeader structure. Second GUID not exists (not matches another GUID in dump folder, then as unknown bytes)
TPkgVersion = record
dwNumber1 : Word;
dwNumber2 : Word;
dwNumber4 : Word;
dwNumber3 : Word;
end;
TDSMHeader = record
dwStructSize : LongInt; // Size of this structure (in bytes) for versioning
dwPackageFlags : LongInt; // Package specific identifiers.
dwProcessorID : LongInt; // what processor (matches defines in winnt.h)
dwOSVersion : LongInt; // what version of the operating system was this built to.
dwPlatformID : LongInt; // what was the target platform.
dwNameLength : LongInt; // length of filename in bytes.
dwNameOffset : LongInt; // offset to Friendly name of package
dwDependentCount : LongInt; // How many entries in Dependent GUID list.
dwDependentOffset : LongInt; // How many bytes from the front of the file are the dependent GUID structs.
dwShadowCount : LongInt; // How many entries in shadow GUID list.
dwShadowOffset : LongInt; // How many bytes from front of file is the array of shadowed package GUIDs.
dwFileCount : LongInt; // How many files are there listed in this manifest.
dwFileListOffset : LongInt; // How many bytes from the front of file to the first FileEntry.
dwCERTDataLength : LongInt; // number of bytes of digital certificate data
dwCERTDataOffset : LongInt; // How many bytes from the front of file to the certificate data.
dwPackageVersion, // Version of this package
dwPrevPkgVersion, // Version of package that this package updates. (0) for Canonical
dwPkgVersion : TPkgVersion; // Version of ... ?!?
guidPackage1 : TGUID; // GUID of this package}
Unknown_1 :LongInt; // Unknown values
Unknown_2 :LongInt; // Unknown values
Unknown_3 :LongInt; // Unknown values
Unknown_4 :LongInt; // Unknown values
end;
TDependentEntry = record
DEUnknown : LongInt; // In my analisys 0 value in all cases
version : TPkgVersion;
guid : TGUID;
end;
dwShadowCount & dwShadowOffSet = Array of GUIDs
dwDependentCount & dwDependentOffSet = Array of TDependentEntry;
Size of DSM file is
sizeof(TDSMHeader) +
sizeof(TDependentEntry) * dwDependentCount
sizeof(TGUID) * dwShadowCount +
FCertificate.Size +
1 + // In DSM exists one byte with value 0 after Certificate ???
length(edFNP.Text) * 2 +
SumFileNameLengths * 2
How to load about dsm in textbox - vb
and sow my friend??
??? Have a Ideas

KB6 ROM (Android 2.2.1) @ Samfirmware for the GT-P1010 (wifi-only Galaxy Tab)

NOTE: the log below pertains to KB5...I haven't had time yet to look into KB6.
http://www.samfirmware.com/WEBPROTECT-p1010.htm
ro.build.display.id=FROYO.XWKB5
ro.build.version.sdk=8
ro.build.version.release=2.2.1
ro.build.date=Thu Feb 17 19:34:43 KST 2011
I'm going to unpack the various RFS archives, to see what's new. I've got a GT-P1000 Galaxy Tab (wifi+3G), so I'm not going to flash with Heimdall (let alone Odin ).
I made backups for factoryfs.rfs / dbdata.rfs etc. using the usual bit-by-bit "dd" -based method, and I've got a trusty TitaniumBackup archive ready, just in case
I notice that TV-out seems to be gone, and FM radio appears to be available. Hardware DSP support seems more present too. (read content logs below for more information)
TAR contents:
Code:
p1wifi_20110128_r10_00.pit (4 KB) (see PIT-info dumped below)
GT-P1010-CSC-SERKB3/
cache.rfs (10.9 MB) (see content listing below)
movinand.mst (51MB) (can be extracted with [URL="http://movitool.ntd.homelinux.org/trac/movitool/"]MoviTool[/URL], based on [URL="http://forum.xda-developers.com/showpost.php?p=9481702&postcount=30"]Volker1's method[/URL])
P1010XWKB5-REV03-ALL-low-CL913814/
boot.bin (256 KB)
cache.rfs (672 KB)
normalboot.img (4.3 MB)
param.lfs (612 KB)
recovery.img (4.3 MB)
Sbl.bin (1.2 MB)
system.rfs (331 MB)
userdata.rfs (1.2 MB)
Output from Volker1's PIT-info utility:
Code:
Contents of PIT file: p1wifi_20110128_r10_00.pit
---------------------------------------------------------------------------
file magic = 0x12349876 (expected value)
Unknown data: 0 0 0 0 0
Number of partitions = 13 (usual value)
Partition #1
Usual content: boot.bin, the primary boot loader (low-level hardware initialization)
partition entry type: 0 0 (normal partition)
ID = 0; flags = 0; unknown: 0
size = 1 blocks of 256 * 512 bytes = 131072 B = 128 kB = 0 MB
unknown string: [........]
partition name = [IBL+PBL.........................]
file name = [boot.bin........................................................]
Partition #2
Usual content: partition information table (PIT)
partition entry type: 0 0 (normal partition)
ID = 0x1; flags = 0; unknown: 0
size = 1 blocks of 256 * 512 bytes = 131072 B = 128 kB = 0 MB
unknown string: [........]
partition name = [PIT.............................]
file name = [p1wifi.pit......................................................]
Partition #3
Usual content: efs.rfs
partition entry type: 0 0 (normal partition)
ID = 0x14; flags = 0x2 (rfs file system); unknown: 0
size = 40 blocks of 256 * 512 bytes = 5242880 B = 5120 kB = 5 MB
unknown string: [........]
partition name = [EFS.............................]
file name = [efs.rfs.........................................................]
Partition #4
Usual content: Sbl.bin, the secondary boot loader (loads linux kernel)
partition entry type: 0 0 (normal partition)
ID = 0x3; flags = 0; unknown: 0
size = 5 blocks of 256 * 512 bytes = 655360 B = 640 kB = 0 MB
unknown string: [........]
partition name = [SBL.............................]
file name = [sbl.bin.........................................................]
Partition #5
Usual content: backup of secondary boot loader
partition entry type: 0 0 (normal partition)
ID = 0x4; flags = 0; unknown: 0
size = 5 blocks of 256 * 512 bytes = 655360 B = 640 kB = 0 MB
unknown string: [........]
partition name = [SBL2............................]
file name = [sbl.bin.........................................................]
Partition #6
Usual content: param.lfs /mnt/.lfs j4fs
partition entry type: 0 0 (normal partition)
ID = 0x15; flags = 0x2 (rfs file system); unknown: 0
size = 20 blocks of 256 * 512 bytes = 2621440 B = 2560 kB = 2 MB
unknown string: [........]
partition name = [PARAM...........................]
file name = [param.lfs.......................................................]
Partition #7
Usual content: zImage, the linux kernel
partition entry type: 0 0 (normal partition)
ID = 0x5; flags = 0; unknown: 0
size = 30 blocks of 256 * 512 bytes = 3932160 B = 3840 kB = 3 MB
unknown string: [........]
partition name = [NORMALBOOT......................]
file name = [normalboot.img..................................................]
Partition #8
Usual content: recovery.bin, the backup copy of zImage/initramfs
partition entry type: 0 0 (normal partition)
ID = 0x8; flags = 0; unknown: 0
size = 30 blocks of 256 * 512 bytes = 3932160 B = 3840 kB = 3 MB
unknown string: [........]
partition name = [RECOVERY........................]
file name = [recovery.img....................................................]
Partition #9
Usual content: factoryfs.rfs
partition entry type: 0 0 (normal partition)
ID = 0x16; flags = 0x2 (rfs file system); unknown: 0
size = 1430 blocks of 256 * 512 bytes = 187432960 B = 183040 kB = 178 MB
unknown string: [........]
partition name = [SYSTEM..........................]
file name = [system.rfs......................................................]
Partition #10
Usual content: dbdata.rfs
partition entry type: 0 0 (normal partition)
ID = 0x17; flags = 0x2 (rfs file system); unknown: 0
size = 302 blocks of 256 * 512 bytes = 39583744 B = 38656 kB = 37 MB
unknown string: [........]
partition name = [USERDATA........................]
file name = [userdata.rfs....................................................]
Partition #11
Usual content: cache.rfs
partition entry type: 0 0 (normal partition)
ID = 0x18; flags = 0x2 (rfs file system); unknown: 0
size = 140 blocks of 256 * 512 bytes = 18350080 B = 17920 kB = 17 MB
unknown string: [........]
partition name = [CACHE...........................]
file name = [cache.rfs.......................................................]
Partition #12
Usual content: modem.bin
partition entry type: 0 2 (unknown value)
ID = 0x3; flags = 0x1; unknown: 0
size = 0 blocks of 0 * 512 bytes = 0 B = 0 kB = 0 MB
unknown string: [........]
partition name = [HIDDEN.D........................]
file name = [hidden.rfs.t....................................................]
Partition #13
Usual content: Unknown
partition entry type: 0 2 (unknown value)
ID = 0; flags = 0x1; unknown: 0
size = 0 blocks of 0 * 512 bytes = 0 B = 0 kB = 0 MB
unknown string: [........]
partition name = [MOVINAND........................]
file name = [movinand.mst....................................................]
The usual CSC cache.rfs content:
Code:
/dbdata/svox/de-DE_gl0_sg.bin
/dbdata/svox/de-DE_ta.bin
/dbdata/svox/en-GB_kh0_sg.bin
/dbdata/svox/en-GB_ta.bin
/dbdata/svox/en-US_lh0_sg.bin
/dbdata/svox/en-US_ta.bin
/dbdata/svox/es-ES_ta.bin
/dbdata/svox/es-ES_zl0_sg.bin
/dbdata/svox/fr-FR_nk0_sg.bin
/dbdata/svox/fr-FR_ta.bin
/dbdata/svox/it-IT_cm0_sg.bin
/dbdata/svox/it-IT_ta.bin
/system/csc/feature.xml
/system/csc/contents.db
/system/csc/others.xml
/system/csc/sales_code.dat
/system/csc/customer.xml
/system/app/MusicODC.apk
/system/T9DB/qwerty_fi.kdb
/system/T9DB/phonepad_cs.kdb
/system/T9DB/qwerty_da.kdb
/system/T9DB/Samsung_400_PLlsUN_xt9.ldb
/system/T9DB/phonepad_lt.kdb
/system/T9DB/Samsung_400_TRlsUN_xt9.ldb
/system/T9DB/Samsung_400_DEusUN_xt9.ldb
/system/T9DB/Samsung_400_ETlsUN_xt9.ldb
/system/T9DB/Samsung_400_ENubUN_xt9.ldb
/system/T9DB/Samsung_400_SVusUN_xt9.ldb
/system/T9DB/qwerty_sv.kdb
/system/T9DB/Samsung_400_DAlsUN.ldb
/system/T9DB/phonepad_uk.kdb
/system/T9DB/phonepad_it.kdb
/system/T9DB/phonepad_el.kdb
/system/T9DB/qwerty_hu.kdb
/system/T9DB/qwerty_es.kdb
/system/T9DB/Samsung_400_UKlsUN_xt9.ldb
/system/T9DB/qwerty_fr.kdb
/system/T9DB/qwerty_et.kdb
/system/T9DB/Samsung_400_SKlsUN_xt9.ldb
/system/T9DB/phonepad_no.kdb
/system/T9DB/qwerty_nl.kdb
/system/T9DB/qwerty_lt.kdb
/system/T9DB/Samsung_400_LVlsUN_xt9.ldb
/system/T9DB/Samsung_400_ITlsUN_xt9.ldb
/system/T9DB/Samsung_400_PTlsUN_xt9.ldb
/system/T9DB/phonepad_da.kdb
/system/T9DB/Samsung_400_HUlsUN_xt9.ldb
/system/T9DB/Samsung_400_ELlsUN_xt9.ldb
/system/T9DB/phonepad_et.kdb
/system/T9DB/Samsung_400_KKlsUN_xt9.ldb
/system/T9DB/phonepad_es.kdb
/system/T9DB/qwerty_sk.kdb
/system/T9DB/phonepad_nl.kdb
/system/T9DB/qwerty_pt.kdb
/system/T9DB/Samsung_400_ESlsUN_xt9.ldb
/system/T9DB/Samsung_400_CSlsUN_xt9.ldb
/system/T9DB/phonepad_ru.kdb
/system/T9DB/phonepad_tr.kdb
/system/T9DB/qwerty_tr.kdb
/system/T9DB/phonepad_de.kdb
/system/T9DB/Samsung_400_FIlsUN_xt9.ldb
/system/T9DB/phonepad_ko.kdb
/system/T9DB/phonepad_fr.kdb
/system/T9DB/phonepad_fi.kdb
/system/T9DB/qwerty_ru.kdb
/system/T9DB/phonepad_en.kdb
/system/T9DB/qwerty_en.kdb
/system/T9DB/qwerty_cs.kdb
/system/T9DB/qwerty_el.kdb
/system/T9DB/Samsung_400_NOlsUN.ldb
/system/T9DB/Samsung_400_RUlsUN_xt9.ldb
/system/T9DB/qwerty_kk.kdb
/system/T9DB/qwerty_no.kdb
/system/T9DB/qwerty_uk.kdb
/system/T9DB/phonepad_lv.kdb
/system/T9DB/phonepad_pl.kdb
/system/T9DB/Samsung_400_NLlsUN_xt9.ldb
/system/T9DB/phonepad_sv.kdb
/system/T9DB/phonepad_sk.kdb
/system/T9DB/Samsung_400_LTlsUN_xt9.ldb
/system/T9DB/qwerty_pl.kdb
/system/T9DB/qwerty_de.kdb
/system/T9DB/Samsung_400_FRlsUN_xt9s.ldb
/system/T9DB/qwerty_ko.kdb
/system/T9DB/qwerty_lv.kdb
/system/T9DB/phonepad_pt.kdb
/system/T9DB/qwerty_it.kdb
/system/T9DB/phonepad_hu.kdb
/system/CSCFiles.txt
/system/SW_Configuration.xml
Changes in /system/app/ :
Removed DailyBriefing, Ebook, Mms, MobileTrackerEngineTwo, MobileTrackerUI, OtaProvisioningService, SamsungWidget_WeatherClock, SoundRecorder, signin, syncmldm, wipereceiver, wssomacp
Added PhoneCrashNotifier, PopupuiReceiverf, qik, qikhelp, skype
Changes in /system/bin/ :
Too many to list, but here are some notable ones:
Removed BCM4329B1_002.002.023.0534.0590.hcd (the driver for the multi-function Broadcom BCM-4329 chipset, also removed in /etc/wifi/ etc.), akmd2 (the multi-sensor driver, now split into several sub-daemons: geomagnetic, gyroscope, temperature, light, orientation, pressure, proximity, etc.)
Notable changes in /system/etc/ :
Added audio/codec/FMRadioEar.ini, audio/codec/FMRadioSpk.ini, and FM-radio stuff in /etc/firmware/ and /lib/libfmradio_jni.so (the Texas Intruments BRF6350 chip supports FM radio...but I don't think that /system/app/ contains an FM tuner application).
Notable addition: /lib/dsp/ + /lib/libOMX*.so + /lib/libVendor_ti_OMX*.so + lib/libaomx_*.so (Texas Intruments OMX/DSP, hardware encoding/decoding of 720p AMR, WB-AMR, AAC, h264, WMA, WMV, MP3, MPEG4, Flac, AC3, S263, etc.)
Code:
720p_h264vdec_sn.dll64P
720p_mp4vdec_sn.dll64P
720p_mp4venc_sn.dll64P
baseimage.dof
baseimage.map
chromasuppress.l64p
conversions.dll64P
dctn_dyn.dll64P
ddspbase_tiomap3430.dof64P
dfgm.dll64P
dynbase_tiomap3430.dof64P
eenf_ti.l64P
h264vdec_sn.dll64P
h264venc_sn.dll64P
ipp_sn.dll64P
jpegdec_sn.dll64P
jpegenc_sn.dll64P
m4venc_sn.dll64P
monitor_tiomap3430.dof64P
mp3dec_sn.dll64P
mp4v720parcdec_sn.dll64P
mp4varcdec_sn.dll64P
mp4vdec_sn.dll64P
mpeg4aacdec_sn.dll64P
mpeg4aacenc_sn.dll64P
mpeg4aridec_sn.dll64P
nbamrdec_sn.dll64P
nbamrenc_sn.dll64P
postprocessor_dualout.dll64P
qosdyn_3430.dll64P
ringio.dll64P
star.l64P
usn.dll64P
vpp_sn.dll64P
wbamrdec_sn.dll64P
wbamrenc_sn.dll64P
wmadec_sn.dll64P
wmv9dec_sn.dll64P
yuvconvert.l64p
Wifi access point doesn't seem very well protected (/etc/wifi/softap/hostapd.conf):
SSID = AndroidAP (not broadcast)
IP = 192.168.43.1
PASS = "password" (WPA)
By the way, the Wifi interface is different than on the fully-featured Tab: tiwlan0 (the access point is tiap0)
Nice let us know what's new and how you make out
This is great news and I am looking forward to your project, thanks!!!
Heads-up: original post updated with PIT partition structure and TAR contents.
Original post updated with further information (FM radio, DSP, etc.). None of this is authoritative, obviously. I am just making plain observations. I haven't even seen the manufacturer's specifications yet for this device.
Splice/combine the ROM with a P1000 ROM?
Cool. Does this mean that your aim to splice/combine the ROM with a P1000 ROM to create a custom Android 2.2.1 ROM WITH 3G capabilities, that is compatible with P1000?
And in that case, it sure would be nice to keep most of what has been removed from /system/* in the P1010 ROM, of course.
Very interesting, thanks for posting the analysis.
I wonder whether GL drivers are any newer than from P1000 ROMs.
And GPS daemon?
Also, interesting about these split sensor drivers.
edit
hmm, interesting, the GL drivers are for SGX530 not 540 like in normal tab.
And the CPU in 1010 is OMAP3 not Hummingbird.
KB6 now online @ Samfirmware.
I'm too busy to look into it though.
Hi,
I just got the Wifi version. How can I check the ROM version?
does the P1010 still have a gps radio?
jackfrostn said:
does the P1010 still have a gps radio?
Click to expand...
Click to collapse
Yes. Only differences between 3g and wifi model:
- no 3G radio
- less powerful CPU/GPU on wifi model (thus can't play HD/Full HD video)
- and off course, wifi model is cheaper
could someone try getting the skype and qik files working
any update on the ROMs progress?
bthoven said:
Yes. Only differences between 3g and wifi model:
- no 3G radio
- less powerful CPU/GPU on wifi model (thus can't play HD/Full HD video)
- and off course, wifi model is cheaper
Click to expand...
Click to collapse
Actually it CAN play HD video. It can record 720p movies so it would only make sense it'd be able to play them. I watch 720p episodes of Breaking Bad on mine.
Sent from my GT-P1010 using XDA Premium App
himmelhauk said:
Actually it CAN play HD video. It can record 720p movies so it would only make sense it'd be able to play them. I watch 720p episodes of Breaking Bad on mine.
Sent from my GT-P1010 using XDA Premium App
Click to expand...
Click to collapse
Yes, it can play 720p lower bitrate whilst the 3G version can play higher bit rate, and also 1080p.
bthoven said:
Yes, it can play 720p lower bitrate whilst the 3G version can play higher bit rate, and also 1080p.
Click to expand...
Click to collapse
Actually it is worth making a correction here as well, it plays 1080 just fine as well, at least for me.
Out of curiousity, where did you see that the wifi has a different CPU/GPU than the GSM/CDMA versions? I'm not finding that info anywhere.
chrisliphart said:
Out of curiousity, where did you see that the wifi has a different CPU/GPU than the GSM/CDMA versions? I'm not finding that info anywhere.
Click to expand...
Click to collapse
In all the TI OMAP libraries and kernel in the ROM?
skype for p1010 wifi
Skype will work with regular rom.i used it all day today
Yes, it does have gps radio on there. Well mine does anyway (in the uk)

Is msm_nand.c broken?

I think msm_nand.c is broken because i got 56 bytes garbage from MEMREADOOB ioctl.
example code snippet:
memset(oobbuf, 0x55, 64);
oob.start = offs;
oob.length = 64;
oob.ptr = oobbuf;
if (ioctl(fd1, MEMREADOOB, &oob) != 0) {
perror("ioctl: ");
return -1;
}
page 0:
00000007E0: FF FF FF FF FF FF FF FF │ FF FF FF FF FF FF FF FF ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙
00000007F0: FF FF FF FF FF FF FF FF │ FF FF FF FF FF FF FF FF ˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙
oob:
0000000800: 13 FD 23 69 75 23 8B 70 │ 52 8A A8 CF 56 CF FA 43 ‼ý#iu#<pRŠ¨ĎVĎúC
0000000810: 09 9F 79 FF A8 CF 56 CF │ FA 43 09 9F 79 FF 01 10 ○źy˙¨ĎVĎúC○źy˙☺►
0000000820: 00 00 01 00 00 30 00 00 │ 00 80 00 00 00 00 88 49 ☺ 0 _ _I
0000000830: 10 E2 F0 4E 39 B0 20 59 │ 55 55 55 55 55 55 55 55 ►âđN9° YUUUUUUUU
page 1:
0000000840: 03 00 00 00 01 00 00 00 │ FF FF 61 70 70 00 00 00 ♥ ☺ ˙˙app
Is it a driver bug? Anyone could fix it please?
htc wildfire buzz - Linux version 2.6.35.13-nFinity ([email protected]) (gcc version 4.4.3 (GCC)
Could it be caused by bad blocks on the nand? Can you provide a binary so I can test?
The blocks are good on this area. Thank you for testing.
You could download the source and binary at:
http://gnet.hu/memreadoob/memreadoob.c
http://gnet.hu/memreadoob/memreadoob
Other problem, I think we can't switch to MTD_MODE_RAW
i got this message in kernel log: msm_nand_read_oob: unsupported ops->len, 2112
but it doesn't contains MTD_OOB_RAW so we are not in raw mode.
cm-kernel/drivers/mtd/devices/msm_nand.c:
if (ops->datbuf != NULL &&
(ops->len % (mtd->writesize + mtd->oobsize)) != 0) {
pr_err("%s: unsupported ops->len,"
" %d for MTD_OOB_RAW\n", __func__, ops->len);
return -EINVAL;
}
}
if (ops->mode != MTD_OOB_RAW && ops->ooblen != 0 && ops->ooboffs != 0) {
pr_err("%s: unsupported ops->ooboffs, %d\n",
__func__, ops->ooboffs);
return -EINVAL;
}
phr3ak128 said:
Other problem, I think we can't switch to MTD_MODE_RAW
i got this message in kernel log: msm_nand_read_oob: unsupported ops->len, 2112
Click to expand...
Click to collapse
I have no such message in my kernel log.
I also ran memreadoob on my phone, and this is the output I got.
memreadoob
size: 262144000
erase size: 131072
write size: 2048
oob size: 64
2048 bytes readed
oob.start: 56
oob.length: 64
2048 bytes readed
oob.start: 56
oob.length: 64
Hi arco68,
Can we access the radio NAND after HBOOT has started AMSS (the radio OS?) I guess it is blocked by the radio? But I've read elsewhere that CWM 2.x can flash a radio.img, so it seems it does have access?
yes because in this test you read 2048 byte not 2112. it's other bug.
so if you see your /sdcard/test.img you will see the 56 bytes garbage on 0x800 instead of 64 bytes correct oob data.
xdbg said:
Hi arco68,
Can we access the radio NAND after HBOOT has started AMSS (the radio OS?) I guess it is blocked by the radio? But I've read elsewhere that CWM 2.x can flash a radio.img, so it seems it does have access?
Click to expand...
Click to collapse
CWM2 can flash radio yes, CWM3 can not. I don't think you want to mess with the radio part though.
phr3ak128 said:
yes because in this test you read 2048 byte not 2112. it's other bug.
so if you see your /sdcard/test.img you will see the 56 bytes garbage on 0x800 instead of 64 bytes correct oob data.
Click to expand...
Click to collapse
Well I have no idea what's correct or not to be honest. I'm sure if it was a major bug that it would have been fixed upstream a long time ago.
Have you tested with kernel 2.6.32, if it's the same?
Which kernel branch used from git for current nightly?
It's based on original HTC sources released on http://developer.htc.com/
My patched version, if you want to download and compile it yourself, is here:
https://github.com/arco/buzz-kernel-2.6.35
So, Are these bad for buzz? git://github.com/CyanogenMod/cm-kernel.git
What do you think who is the maintainer of msm_nand.c ?
When will be available 2.6.37 for buzz?
So, Are these bad for buzz? git://github.com/CyanogenMod/cm-kernel.git
Click to expand...
Click to collapse
Yes, it's for snapdragon devices.
phr3ak128 said:
What do you think who is the maintainer of msm_nand.c ?
When will be available 2.6.37 for buzz?
Click to expand...
Click to collapse
Google/Code Aurora, and probably some code done by HTC.
2.6.37 won't be available for the Tattoo. Anything higher than 2.6.35 I don't think will happen, unless some new phone with similar specs as the wildfire comes out with a newer kernel. And even then it could be impossible.
I see the msm-2.6.35 mtd driver is newer than yours. How possible this? I tried to complie that with msm_defconfig without success.
It's not compatible with our phone.
What is the problem with that, Is that not support MSM7225?
Think of it like this, you can't use the drivers for a Nvidia GeForce 9 card on an old GeForce 2 card, can you? If you understand what I mean?
phr3ak128 said:
What do you think who is the maintainer of msm_nand.c ?
When will be available 2.6.37 for buzz?
Click to expand...
Click to collapse
It's possible, but a huge amount of work. Porting all the hardware and making sure it works fine is really not trivial. It's time consuming, and the benefit right now of using 2.6.37 instead of 2.6.35 is unclear to me.

Categories

Resources