point of concern!

[cjard]

rolis 477 gives me this:


------------------* Nokia Mobile Info *---------------------------
SoftWare & HW : V 05.13.11-01-02.NHM-5.(c) NMP.
Flash ID : 00200090,ST M28W160T, ALIAS_ID=00898890
-----------------------------------------------------------------------
MCU SW CHK test ............................ Ok.
LPCS [0x13002C..0x13025F]= 0x96498FF2 ... Ok.
GSMC [0x130260..0x130413]= 0xC216F3AD ... Ok.
FONT [0x130414..0x131EEF]= 0x96824BA7 ... Ok.
TEXT [0x131EF0..0x15163F]= 0xBE69B304 ... Ok.
AORD [0x151640..0x151CC3]= 0x89312DE1 ... Ok.
TONE [0x151CC4..0x15335B]= 0xE50C62E1 ... Ok.
PLMN [0x15335C..0x154EE7]= 0x43D3198B ... Ok.
LDB [0x154EE8..0x1A347F]= 0x891AA30E ... Ok.
DUMFILE [0x1A3480..0x1A34A3] ............... skipped
Area after DUMFILE ......................... OK.(0xFF)
Tune CHK test .............................. Ok.(0x8A60)
Security CHK test .......................... Ok.(0x9749)


each time i read my phone.. looks okay, yeah?

im making many backups of my phone. im doing this by reading the flash, saving it, reading again, saving it as a different name.. etc
i have read the flash 5 times now, and i wrote a small utility to compare the files... the files are all different!

the firs 1.9 megabytes or so, of each file is the same, then the different blocks start. the first file was just full off FF FF FF FF at the end, the second time i read it.. some of those FF FF changed to other hex values
the third time i read it, some of those that were FF FF in the first 2 files, changed to other haex values...

can you see, that each time i read, what was empty space is either re-read as having data there (i.e. did rolis fuck up the firs times, and there really is data there) or maybe the phone, each time i do a read, is changing the contents of the flash memory, so i get a different read each time?

can anyone tell me whats going on?


.
.
.


attached is a dump of the output from my utility (its an n-way file comparison util. if anyone wants it cos its the only thing i know of can compare more than 2 files at once, just say)
the left most hex column is read out of the FIRST flash file i created. the subsequent flashes are on the right of that.. the more right you go, the more recently i read the flash.
(for the last flash, instead of connecting the charger, i pressed power on, and used battery power to read the flash)

ahh,, shit.. i just accidentally over-wrote one of the flash files (file number 4 in a set of 6) with a more recent flash read, this means that between column 4 and 5 there should be another column with, im guessing, half of the differences as FF and half as (other data). no matter tho, you get the general idea..

heres another weird ass thing.. the last 2 reads are done on battery power, not on the charger (when rolis said power-on the phone i pressed the power button. i USED to plug in the charger)
note that the last 2 reads are the _same_ inside. (the reason they show up is that the comparator logic doesnt compare each file with each other.. that gets too difficult too quickly. it merely compares each file with file number 1. any difference in any file causes the a report of each file's content byte at that point)

[DaveGSM82]

I cant help you with your flash problem other than to say upload a new flash with a brand new virgin eeprom and see if it works. your little app seems quite interesting, could you post it for us?

Cheers, Dave.

[sandra02]

it might be abug in rolis 477. try using 5.14

[User32]

don't bother with such small details. since there is no problem modifying the flash file, why search about it so much?
"curiosity killed the cat" thay say (irrelevant here...:))

[cjard]

well, i was interested to see if the reading of the flash is reliable.. cos you never know.. sunspots or cosmic radiation etc, might mean that you read a backup of your phone, onto the pc.. save it, but it contains just one little error, and thats it.. if i fuck up the [hone, i wanna be able to flash back to the original state

the problem comes because i cant, or couldnt, create a nokia flash file that was consistent between 2 successive reads. if you made a backup of your phone that was only 97% guaranteed to be correct/accurate.. would you trust it?


attached is nCmp.class
you need a java virtual machine to run it. the usage is:

java nCmp "fiilepath1" "filepath2" ... "filepathN"

to pass in paths with spaces, use quotes. otherwise, it is not essential. when comparing files of different sizes, comparison only takes place up to the size of the smallest file (comparing a 1 kilobyte file with 1 megabyte, only the first 1 kilobyte of the meg , is analysed)

the zip file includes the source too.. i hereby put it in the public domin. be warned, it took nly about an hour to hack it toogether. it's rough! if it desperately needs a gui, let me know; ill think about it :)

matt