On 11/02/2011 1.26, Aaron Carroll wrote:
Hi Luca,
On 11 February 2011 02:00, du...@dummy.com<du...@dummy.com> wrote:
On 10/02/2011 11.10, Aaron Carroll wrote:
On 10 February 2011 06:19, Luca Ellero<lro...@gmail.com> wrote:
This patch adds read/write capability to memory addresses not
accessible through AHB-AP (for example "boot ROM code").
To select between AHB and APB, a "dap apsel" command must be issued:
dap apsel 0 -> following memory accesses are throuhg AHB
dap apsel 1 -> following memory accesses are throuhg APB
Seems a weird usage of apsel. Could this be made more general, say a
command to set the memory access type (core, hostbus, etc). "dap
apsel 0" isn't very informative to users.
...well, yes, it is. But I didn't find a better way, without heavily
impacting other architectures.
Anyway, apart from getting some info on AP (which actually is wrong on
cortex_A9) what is the exact usefulness of "dap apsel"?
Good question, I have no idea. Regarding incorrect "dap info", I
think actually it's a correct interpretation... the APB-AP ROM is
empty on all the omap4430's I've tried.
Maybe it has to be set at dap level (in arm_adi_v5.c), but here it will
eventually end-up in something like "dap apsel"?
Have you any suggestions?
Firstly, I don't think this is really a DAP or even an ARM issue. In
general, there may be multiple ways to access main memory (through the
core, through any number of direct bus connections... perhaps there
are others), and this should be configurable. I think the right
solution is some combination of:
1) a flag to the memory-accessing commands;
2) a table of memory regions to access methods. Probably this has
some per-SoC/board defaults which can be amended/overridden in .cfgs.
3) a global user-configurable default.
(3) is more-or-less what you've done. If we have a per-target
configuration parameter (memtype_default, memaccess_default, something
like that?), then the relevant target code can check it before
performing the access.
Maybe the best way of doing it is a per-target callback. This way,
the memory access types don't need to be defined globally, targets can
check that valid access types are specified, and it provides a nice
transition... empty callback means it isn't supported.
I agree, I'll investigate a bit to see if we can find a good solution.
Anyway I think that this is a decision that must be approved by the
majority of developers, because it impacts heavily all the source code
and documentation. We have to keep in mind that also other commands use
memory access, for example "arm disassemble", "dump_image", "load_image"
I'm quite new in developing openocd, so I think I'm not the right one to
take this decision ;-)
cheers
luca ellero
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
