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. Cheers, -- Aaron _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development