Feature request: DMA-powered checksums

[dansanderson]

Feature request: an extended DMA job type for calculating fast checksums of data in memory.

One application of Attic RAM is to act as a cache of static data. Because Attic RAM cannot be frozen, it is possible for a program that uses Attic RAM in this way to be frozen at any instruction, and resumed with Attic RAM in an unexpected state. Some programs might want to support freezing between points in a user workflow, or otherwise support the user stopping and restarting the program with other programs run in between, using Attic and a short dispatch routine that stays resident in chip RAM. The program would test Attic RAM on re-entry to determine if its cache is invalidated and re-load from disk as needed. A simple check of a short validation string detects a complete erasure of Attic RAM (e.g. from a cold boot), but might miss other cases where it's the same session but other apps have run between states.

I'm especially thinking of developers tools. For example, Eleven does this with a two-byte validation string. I'm working on a developer tool with a similar need, and will resort to testing a version string at a fixed location without another fast solution.

One possibility: implement an extended DMA job type for calculating a checksum over a source region, and writing it to a destination address. If this were a checksum algorithm suitable for spotting unexpected changes, Eleven et al. could validate the Attic cache and use or refresh it as needed.

Open questions:

1. Is a one-byte checksum at a "held" destination address sufficient for this application? If not, could a job type emit a fixed number of bytes to a destination region for a useful checksum value size?
2. Would a carefully chosen checksum algorithm be useful for other applications, such as validating network packets? Are there standards that would dictate which algorithm(s) to support? Could/should this support different algorithms selectable by job token?

[lydon42]

Totally selfish toughts:

A CRC32 checksum is used in MEGAFLASH for the core files. If we could do that in DMA, and also keep the in between result to do incremental updates, I could replace this, which would free up some space for other features. MEGAFLASH is always tight.

Using something like MULTINA for the 32bit CRC could be a possibility. We could also add an DMA option specifying a base page address where the 32 bits of checksum are stored.