Testing flash (Was: [rfa] NEWS additions for flash)

[Vladimir Prus <ghost@cs.msu.su>]

Daniel Jacobowitz wrote:

> On Thu, Sep 21, 2006 at 12:10:56PM -0700, Michael Snyder wrote:
>> On Thu, 2006-09-21 at 10:18 -0400, Daniel Jacobowitz wrote:
>> > This patch adds news entries for the flash patches I've just checked
>> > in.  Is this OK?
>> > 
>> > The next release is shaping up to be quite an improvement.
>> 
>> On a quick scan of your (today's) patch, I don't see any tests.
>> Is this testable?
> 
> In theory, you could write some tests for it using 'gdbreplay'.  But
> getting gdbreplay to work in the testsuite harness would be quite
> tricky, and it would be complicated by the fact that which registers
> GDB asks for at connection is target dependent; I don't know how to
> write generic remote protocol tests.
> 
> I'd love to unit test this stuff.  If you have any suggestions, I'm
> all ears.

Assuming not everybody has boards with flash handy, and burning flash every
night is bad idea, we need some 'fake' setup anyway. For example, we can
take any remote test and then:

  - Fabricate memory map that has flash regions. Such memory map can
    be fixed, having no relation to actual remote target. 
  - Log all flash packets without passing them to remote side.

I think we can either have special 'flash debug mode' in gdb, which reads
memory map from a file you specify and writes flash packages to another
file you specify, or man-in-the-middle between gdb and real remote that
does the same. I'd suspect adding flash debug mode in gdb would be simpler.

Ah, and I supposed that if we want to match generated flash packets to
expectation, we need to 'load' a fixed *binary* -- not binary produced from
sources, but a binary added to CVS.

- Volodya