On Sunday 28 March 2010, Maximilian Odendahl wrote:
> Hi everyone,
>
> What is the current state of the Cortex A8 support? Is the info on[1]
> still up to date?
It references SVN, so ... clearly not! But the functional summary isn't
far off.
> I guess the final goal would be to be able to fully
> debug Linux as well as other OS's using OpenOCD(I'm also interested in
> getting this to work with Symbian, as a cheap solution to debug the
> kernel is currently missing completly).
For kernel debug, MMU support will surely be one thing to address.
> As I do not have too much insight into the current state, would
> someone be able to break down the missing task into smaller steps? I
> could then propose this to my university supervisor at the same time.
I'd distinguish between A8 support and OMAP3 support. They're not
entirely the same. The MX51 chips don't "just come up" for example.
There's a bit of generic CoreSight/DAP work to be done. Some of it
has FIXME comments in the ADI v5 or A8 suppport code ... A few things that
come to mind include:
* Don't hard-wire assumptions about the DAP. Look at its ROM table and
use the data there .... instead of assuming fixed numbers for the debug
AP and mem AP, and debug_base. Save any ETM or ETB addresses. THere's
currently a bunch of code wrongly assuming A8 == OMAP3.
* Look at details of debug entry/exit and fix a lot of the corner cases
that are currently fudged. The ARMv6/v7 spec is clear that much behavior
should be shared between ARMv6 (ARM11) and ARMv7A) (Cortex-A) suppport ...
the DPM code doesn't share as much as it should.
* Along those same lines .... hard and soft breakpoint support for ARM11 and
Cortex-A8 should be almost identical (arm_dpm.c). ISTR that A8 doesn't yet
have hard breakpoint support and ARM11 doesn't yet have soft, or maybe it's
the other way around.
* At some point ThumbEE support will deserve attention. I don't know of
anything relying on that mode yet, but surely that will come in time.
* A clean way to tell GDB exactly what kind of core is present .... there's
a way to do that with some GDB qXfer feature descriptor. DO it right, and
the floating point registers will no longer be pure lies. (Nothing uses FPA
any more, while OMAP3 has VFP3 ISTR ...)
* Minimal suport for XDS100 JTAG adapters could be useful. Don't get caught
up in the legal issues there (TI has some strange licensing for schematic
data) but maybe there's some bare-bones support possible without relying on
more than the obvious (FT2232 uses four signals for JTAG, regardless)
that'd
be easily customized .... at least, a private driver may be helpful for your
own work.)
One reason to care about xds100v2 is that it's got adaptive clocking
suppport
which means you can cope with the clock speed variations that Linux, for one
example, will introduce. WHen the core lock gates off, you will need to
make
sure you can still communicate over JTAG. (This is another reason to want
the
ICEpick reset functionality...)
Well, that's a start. Please send around what you come up with, so we can
give you some review before you dive in too deeply.
- Dave
[1] http://elinux.org/BeagleBoardOpenOCD
> _______________________________________________
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
