Re: memory verify

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> Those that implement it with a 'srecord verify'-like mechanism
>> would lose (some ROM monitors have a command where a srecord stream
>> is compared with the contents of memory instead of replacing the
>> contents).  But perhaps this is an argument against using that kind
>> of implementation.  Thoughts?

Andrew> Bleuk :-)
Andrew>
Andrew> That suggests one requirement on that method is that it be
Andrew> significantly faster than a simple memory read :-)

It's a matter of degree.  A 'srecord verify' based implementation
might be faster than reading memory on a high latency link, but will
be still be much, much slower than a checksum bashed implementation.

But after reading the description of the PPCBug VE command, I'm not
sure that I'd want to use that.  If there are less than three srecs
that are different, it doesn't bail out early.  This would be a lot
slower than reading and comparing chunks if the differences were near
the beginning of a region.  And parsing the output would be about as
much fun as pushing a pea up a mountain using only your nose.

The PPCbug CS command only does simple byte, half-word, and word 
based checksums.  I wouldn't trust that even if I did all three.

Other monitors may be a bit better or a bit worse, PPCBug is the 
only thing I have handy.

I didn't want to preclude any implementation, but perhaps we should
'recommend' that verify be a strong checksum/crc/or hash and assume
that it is.

        --jtc

-- 
J.T. Conklin
RedBack Networks