Hello,
Some of you may remember me - from a while ago: I am same
"[email protected]" - I am glad to see many new names, and some familiar
names.
I have some questions about the OpenOCD roadmap specifically plans to support,
timeline roadmap, etc.
This is a long laundry list ... and is in no particular order and in many
cases, some of my questions are inter related
1) 64bit support in general (while my questions are from an ARM
perspective, these are really generic)
Note: It is not as simple as changing all of the address parameters
from "uint32_t" to "uint64_t" - it is a pervasive change that will affect the
function signatures in the 'target' API block in big ways - Seem Item #2 as it
applies to this issue as well.
Question: What are plans to support 64bit in general? Is there a roadmap you
have in mind?
2) Again - not ARM specific - as these apply to other targets as well.
Today, there is limited support for the "phys" keyword in some memory commands,
but not all commands. Problem is, there are far more than just PHYS support
that is required - it can become a permutation nightmare.
*Example:* Generically, stop and gain control of the target. The CPU is in some
(RANDOM MODE: Kernel, User, Secure, Hypervisor, Trustzone, or other N
combinations). While the CPU is stopped - I need to read/write memory
locations that are behind a some access control (ie: phys, not virtual memory
mode, or secure access only)
This is really extending the phys attribute (and function) N x M permutations.
As a thought experiment: (Phys/Virt = 2) times (Arm64: Hypervisor, Trustzone,
Kernel, User = 4) times (Secure vrs NonSecure = 2) a total of 16. I know that
there are other CPU specific formats that are disjoint from the ARM example and
need their own list of funky solutions.
You can also think of special CPU memory spaces - ie: The L1 and L2 caches -
can you dump each cache layer so that you can debug a cache coherency problem
(multiply by 4 = 48)
3) There are also non-CPU based ways to access memory
For example in ARM - there is something called the DAP, which has multiple
downstream memory ports. Some of these ports might be 64bit - some might be 32
bit - and you can have a mixture on the same chip you can read and write memory
directly via the ARM dap bypassing the CPU
Thus - while the system is running, without stopping the CPU - the debugger can
update a memory window with live information without interfering with the CPU.
This too has memory attributes, such as security, route number or memory space
- more permutations.
What I am leading to (in items 1, 2 and 3) is something more like a "struct
target_address" - instead of a simple integer, that can specify a memory
location for certain operations. This type of change Is *BIG* in openocd.
Do you have any plans, or road map to deal with these types of problems?
4) Currently, openocd does not support an ARM feature known as the JTAG-AP
- it is a DAP feature.
Without getting into more details, means a major overhaul of the entire
JTAG infrastructure
The reason is: There would be layers of JTAG ... example:
The transport for some cores would be SWD, but other cores would be
JTAG that is tunneled through the SWD interface
Or a JTAG interface that is tunneled through another JTAG interface.
Any plans or desire to support this?
5) Linux Kernel Debug
I saw some email earlier from Paul Fertser - about Linux Kernel Debug with
OpenOCD - what is the status of this activity? What is the current road map?
6) What about Multicore - opens another can of questions
There is the simplistic case (some limited support) when all CPUs
remain powered up and on line - there is also the case where various CPUs
power down dynamically to save battery - this changes the definition of the
"target poll" operation - and what it does
What are the plans there? Any road map ideas?
7) There are also cases where you connect - and only the "boot" processor
is powered up (it might be a tiny micro-controller you have not heard of). The
boot system loads boot code into memory, validates checksums then later brings
the other CPU on line, seconds later is when you can actually attach and debug
...
This changes the target initialization sequence - today, OpenOCD
assumes all targets are "powered up and ready" at startup. They might not be
present or even powered up yet.
Any plans or thoughts here?
8) How best to represent or expose the *non* software debug items in the
higher level debugger (example: LLDB, GDB, or Eclipse).. They have no concept
of an MMU page table, or cache memory, physical memory, or what a clock tree
might be - let alone access restrictions (ie: 32bit non-burst access only,
16bit is not allowed)
An example would be something like this:
http://www.keil.com/dd/vtr/4868/13887.htm
This shows a list of clocks, their current frequencies, and includes a nice
info-graphic with annotations that describe the breakdown of clock control bits
and the resulting frequencies at key points in the clock distribution. Don't
think that this is limited to HW registers, it could also be data structures
used by an USB EHCI controller.
=====
I have many more questions, layers of questions - the above is the first
"round" of questions
What I'm hoping to do with this email is open up a discussion about roadmap,
and plans for OpenOCD.
We are interested in learning what your plans are more formally.
-Duane Ellis
Qualcomm
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
