--- On Tue, 11/2/10, Øyvind Harboe <[email protected]> wrote:

> 
> I don't know what the answer is long term. I would, like
> you,
> like to hear thoughts from others on this.

There's a bug filed about us not reporting the
memory maps correctly, with specific reference
to RAM/SRAM regions.  Fixing that would help
make GDB behave better ... it'd use different
commands to write flash vs RAM, etc.

There are three parts to that problem:  collecting
and saving that region info, and most simply,
feeding it to GDB with the rest of the mem map. 


My current thought is:

 - internal API to declare RAM/SRAM regions to
later be reported to GDB (or used internally).

Call that API via some Tcl script command that
takes address and size, in at least some config
scripts (if we must).

For some chips that info is easily gotten
via chip probe, instead of model-specific
(and messy/error-prone) config files.

For example the Stellaris chips report
how much SRAM they've got in "flash info", but
that info could be stashed via the API and then
accessed later.

Other chips may need to have drivers consult
tables driven by part numbers, working a bit
differently from the Stellaris chips.  I'm not
suggesting a place the chip probing should be
done; sometime during setup, obviously.

THere could be a command that says "allocate some
of the RAM/SRAM for a work-area".  I suspect the
different flash drivers would want different
defaults for work area sizes.

- Dave



_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to