From: Paul Guyot (pguyot_at_kallisys.net)
Date: Wed Feb 02 2005 - 21:36:53 PST
Aux environs du 2/02/05 à 19:01 -0500, sous le titre "Re: [NTLK]
Einstein Emulator won't load viewframe", Sonny Hung prit sa plus
belle plume pour écrire les mots suivants:
>On Wed, 2 Feb 2005 22:25:53 +0100, Paul Guyot <pguyot_at_kallisys.net> wrote:
>
>> This bug is known and has been fixed in the development tree.
>> I also figured out how the calibration information is stored and why
>> the system patch doesn't stick. As soon as I'll have fixed this
>> latter problem, I'll release a new build.
>
>Hey Paul,
>
>Hopefully I'm interpreting you correctly.
>Are you talking about the Factory Calibration regarding the digitizer?
>Then there may be a way to fix it on the Newton? or just in the
>Einstein Emulator?
I'm talking about the factory calibration that the Newton talks about
when it says: "Factory calibration has been lost, bla bla bla, this
unit needs immediate repair, batteries won't be charged". I think
this calibration data concerns the real time clock and the
temperature chip.
What I figured out is that this calibration data is written on both
block 0 and block 1 of flash. During a system patch installation, the
patch is written on block 0. On boot, if the calibration is invalid
on block 0, it is copied from block 1 to block 0. If it's invalid on
block 1, default values are applied. Block 1 is considered as a
fallback, somehow.
The data I decoded is the following (for each block):
+00 444C4453 'DLDS'
+04 4F534344 'OSCD'
+08 0000010C calibration size
+24 written to 0F241800 (*), default: 00003916
+34 written to 0F280000 (*), default: 0000465A followed by a write of
00001816 to 0F280400
+3C written to 0F180400 (*), default: 00008000
+40 manufacture date (*), default: 00000000, base: january, 1st, 1904.
+50 444C4453 ('DLDS')
+54 checksum of the block
+58 some negative number, -4 for block 0, -0x10 for block 1, -8 and
others seems also valid
+5C patch size, if any
+8C FFFFFFFF -> calibration data is valid, 0x686A6372 ('hjcr') it's invalid.
The block 0 also includes ROM checksum.
+64 Base Checksum High bits
+68 Base Checksum Low bits
+6C Rex0 Checksum High bits
+70 Rex0 Checksum Low bits
+74 Rex1 Checksum High bits
+78 Rex1 Checksum Low bits
+7C Rex2 Checksum High bits
+80 Rex2 Checksum Low bits
+84 Rex3 Checksum High bits
+88 Rex3 Checksum Low bits
During the copy from block 1 to block 0, the system will write
0x686A6372 at offset +8C if it considers that the calibration is
invalid.
The test of the validity is then later performed during boot by
looking at the value on block 0.
The four longs concerning the calibration are those marked with a star.
What I fixed is that now, if the flash is empty, it's initialized
with proper values for the calibration. So the calibration lost
message no longer pops up on the emulator.
I'm more reluctant for hardware units. There is a real risk of
damaging the unit permanently. But I did plan indeed to write a
program to dump and restore the factory calibration data.
I have only figured one of the four 32 bits words of the calibration
data. I don't know what the three other are used for.
Paul
-- Ministre ultraplénipotentiaire en disponibilité. Baignoire à vendre. http://www.kallisys.com/ http://newton.kallisys.net:8080/ -- This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries Official Newton FAQ: http://www.chuma.org/newton/faq/ WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/
This archive was generated by hypermail 2.1.5 : Thu Feb 03 2005 - 00:00:01 PST