Hi Paul
I've done a comparison of the targets using cortex-a architecture, to find
out which specifies dbgbase, and which do not specify dbgbase - which would
then be read using the two functions I mention below. These functions are
only called when no dbgbase is specified in the target tcl script, to try
and get the debugbase from the ROM table.
if (!target->dbgbase_set)
dap_get_debugbase(swjdp, 1, &dbgbase, &apid);
dap_lookup_cs_component(swjdp, 1, dbgbase, 0x15, &armv7a->debug_base,
&coreidx);
The following targets all specify dbgbase in their cfg files, thus ROM
table lookup is not used:
omap4430.cfg
omap4460.cfg
am335x.cfg
bcm281xx.cfg
imx6.cfg
zynq_7000.cfg
altera_fpgasoc.cfg
u8500.cfg
The following are the targets that do not specify dbgbase in their cfg
files:
am437x.cfg
amdm37x.cfg
omap3530.cfg
armada370.cfg
imx51.cfg
imx53.cfg
Unfortunately I do not poses the necessary hardware to verify if passing
the coreidx as the 2nd parameter to the above mentioned functions will
correctly read the ROM table for the above mentioned boards. I only have
the SAMA5.
But, the fact that more than half of the boards specify dbgbase tells me
that there is an issue with looking up the dbgbase from the ROM table, and
that hardcoding the access port for looking up the dbgbase might be the
issue.
Regards
Olivier Schonken
On Sat, Jan 3, 2015 at 6:26 PM, Paul Fertser <[email protected]> wrote:
> Hello,
>
> Thank you for the information about SAMA5 AP arrangement.
>
> On Sat, Jan 03, 2015 at 04:28:42PM +0200, Olivier Schonken wrote:
> > The second parameter passed in both functions is the access port index
> > (currently hardcoded to 1). For the SAMA5D3x chips, hard coding the ap
> to 0 in
> > the calls to these functions causes the ROM table to be read correctly
> without
> > specifying the dbgbase when creating the tap, because it has only one
> dap for
> > core 0.
> >
> > I don't have hardware to test other Cortex-A multi core implementations,
> but I
> > suspect that using the coreidx variable that gets set to the target
> coreid might
> > be a possible solution here. (When not specified this is set to 0).
>
> I'm certain this is not matching the majority of the devices already
> supported by OpenOCD. All SMP cores I've seen so far had ROM table
> entries on the same AP.
>
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:[email protected]
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
