Printable View
Hallo everybody,
does anybody of you know how to calculate the checksum on the end of PPM right after the 2 byte MCU checksum? I think this is the only way how to get my T9 upgrade problem solved. I have Nfree 1.3, but I think this software doesn't make the calculation. The checksum is on the position 39FFFC.
Could anybody share his knowledge about checksum calculation algorhytm?
Thank you.
phone-crash
what is your phone type , And version ??
i cant help you putting T9 on your phone without calculating ppm end checksum
Hi.
I don't know the calc or which proggie does.
So I also hope someone replies to this question.
To Mr. phone-crash:
- Why U think that this ppm checksum has influence on Ur T9 modification works? (my psych. wants to know, not me)
- (39FFFC) = 00(19).FFFC, better?
NokDoc
to mehdi>
It is a 6210 v 5.56 language pack H.
to NokDoc's psych.>
Because i have replaced the czech T9 dictionary with the Slovak from a 3330 v 4.50. This dictionary is a bit larger and also containsother data then the original. Therefor I think the checksum has to be recalculated. Without this the phone resets after 30 sec. even when I calculated the FAID with Nokiatool from B-freaks. Other way to calculate FAID didn't work (calculator + logger). I've got wrong PPM checksum. Somehow I don't understand your irony.
Hi again Mr. phone-crash,
Only because ppm checksum has to do with Faid calculation I also only 'think' it is important.
But I don't know if it really is important or is the base of our problems.
So that's why I tried to ask Ur ideas about it.
NokDoc
If one of ppm chksum or mcu chksum is wrong .->contact service.
If phone asks pin then faid might be wrong.
Some times loggers calculate wrong faid to phone so use mbus faid updater.
nokiaguru.gsmsearch.com
There is also ppmfixer for calculating ppm chksums.
The last xhecksum is calculated by KNOK 21.....
Hope this helps.....
You must first emulate connection and then choose flash file......
Hi Abe,
Can you explain in more detail how did you do it? Maybe with an actual example (take a virgin file, show the changed values, run the program note what was modified, change a byte, run the program, show changef values)?
I have tried kNok on a virgin 5110 file. Chosen emulate communication from file, check and fix checksums from the menu and then compared the original with the modified file. I found that the only the MCU checksum was modified at 22 and FFFFB (should have been FFFFA). On a second run the MCU checksum was put additionally in EFFFB.
Something does not seem right...
BR,
ldril
I'm sorry, but with knok21 I have experienced bad situations. It didn't calculate the PPM checksum and it calculates the second MCU chck shifted one byte to right. That must be a hard bug.
phone-crash
to NokDoc.
One more question.
(39FFFC) = 00(19).FFFC
I still can not understand the conversion from 39 to 00(19). Can you give me some more info about this format? Thanks.
phone-crash
Hi guys,
>> (39FFFC) = 00(19).FFFC
It is no conversion, this is all about difference between relative or absolute addressing methods.
Still we are talking about the same bytes, the last 4 bytes in ppm area, we started to call the ppm checksum.
Since we all start flashing at 0020.0000 it is normal we think our first byte is 0000.0000 while it should be the 0020.0000.
This will make the Relative address 00(19).FFFC an Absolute address of 00(39).FFFC.
I added the brackets because of accentuating here the differences may occur between different phone types
Type Relative Absolute
5110 00(0F).FFFC 00(2F).FFFC
3310 00(1C).FFFC 00(3C).FFFC
6210 00(39).FFFC 00(59).FFFC
And now kNok 22 revision:
The MCU problem is gone now, no contact services anymore,
The checksum calc gave a 4 byte value.
The checksum & correction corrected the last 4 bytes, only with other value as the one displayed! (see picture)
I tested both of these numbers manually, both have working MCU, but no network.
Surprisingly for me they do both result in SAME FAID number calculated?
To be continued...(I hope)
NokDoc
The picture
Funny detail about the displayed value in kNok:
Calculated flash checksum: 1C 70 7C 52
From Tek's/ fchk.c calc, Flash Chck: 52 7C 70 1C
Reversed order.
NokDoc
The reverse values could be due to the fact that Nokia proc uses big endian and Intel uses little endian byte ordering. Maybe one program displays the 4 bytes in order and the other displays them based on Intel ordering.
if i put his checksum caculated by knok21 at the end of ppm it will calculate good faid with bh and rolis tool ??