[Open SoC Debug] Good Summer of Code - I am your mentor

SHIVAM AGGARWAL shivam16195 at iiitd.ac.in
Mon May 7 14:46:43 CEST 2018


Hi,
I believe now I have a firm understanding of CDM module. Please validate
the details I mentioned on the basis of my understanding. It will be
relatively easy to work on the specification after this point.

On Mon, May 7, 2018 at 12:40 PM, Philipp Wagner <philipp.wagner at tum.de>
wrote:

> Hi Shivam,
>
> I've forwarded this to the opensocdebug mailing list, please keep all
> technical discussion there.
>

Noted.

>
> On 05/06/2018 10:07 PM, SHIVAM AGGARWAL wrote:
>
>> Hi,
>>
>> Thanks for reviewing my PR. I understood all the changes and will update
>> them shortly. I read about or1k debug registers thoroughly and very briefly
>> about GDB internals. Please clear thesefew basic queries about the project.
>>
>>
>> *My understanding of GDB and debugging system*:
>>
>> GDB helps in setting watchpoints and breakpoints in the program code to
>> debug the program running on the soft-CPU core (here, or1k).
>>
>>
>> A breakpoint is a user-designated location in the program where the user
>> wants to regain control if program execution ever reaches that location.
>>
>
> yes
>
> A watchpoint is a location where the user just wants to see the program
>> state without actually breaking the program flow.
>>
>
> no, a watchpoint is a break based on the value of a variable.
>

Thanks for the clarification.

>
> Now, for instance, I want to set a breakpoint at line 5 in the below code.
>> This address value is loaded (write operation) into one of the registers
>> mapped in CDM module, which in turn is transferred over or1k debug register
>> (DVR-DCR pair). Now, during program execution, if the program counter ever
>> matches a value in a breakpoint register (read operation), the CPU raises
>> an exception and reports it to GDB.
>>
>
> Yes. Note that the "raises an exception and reports it to GDB" part
> requires more actions in between, since GDB cannot magically know that an
> exception happened. That's why you need to send out an debug event packet
> in this case.
>

> 1. #include <stdio.h>
>> 2. int main()
>> 3.   {
>> 4.   // printf() displays the string inside quotation
>> 5.   printf("Hello, World!");
>> 6.   return 0;
>> 7.    }
>>
>>
>> This Breakpoint location address will be stored in DVR (Debug Value
>> Register) and its corresponding Data Control Register value will be:
>>
>>
>>
>> Bit
>>
>>
>>
>> 31-8
>>
>>
>>
>> 7-5
>>
>>
>>
>> 4
>>
>>
>>
>> 3-1
>>
>>
>>
>> 0
>>
>> Value
>>
>>
>>
>> Reserved
>>
>>
>>
>> 010
>>
>>
>>
>> 0
>>
>>
>>
>> 001
>>
>>
>>
>> 1
>>
>> Comments
>>
>>
>>
>> No need to worry about this value.
>>
>>
>>
>> Compare to Load EA
>>
>>
>>
>> Compare using unsigned integers
>>
>>
>>
>> 001 Equal
>>
>>
>>
>> Corresponding DVR/DCR pair is present
>>
>>
>> “The DCRs are programmed with the watchpoint settings that define how
>> DVRs are compared to the instruction fetch or load/store EA or to the
>> load/store data.”
>>
>>
>> Queries:
>>
>>  1.
>>
>>     I have decided these values based on the document (chapter 10)
>>     https://openrisc.io/or1k.html. Some of these values (bits 1-4) can
>>     be set as default. Which part of the project will be responsible to
>>     set these values?
>>
>
> I don't understand the question. What do you mean by "which part of the
> project"?
>
>  2.
>>
>>     Why are we mapping these DCR registers to OSD specific registers. We
>>     can first store breakpoint address into OSD registers (write
>>     operation) and then set the above values into the or1k debug
>>     register DCR. Am i missing something?
>>
>
> Can you outline in more detail what you exactly mean here? E.g., which
> specific steps do you think will be taken? (Who communicates with whom and
> what messages are being exchanged. You can draw this up as a message
> sequence chart if you want.)
>
> Can GDB handle these values on its own? If yes, then mapping these
>> registers will surely be advantageous.
>>
>>  3.
>>
>>     For all the other or1k debug registers, it is mentioned that the
>>     “value is set by the resident debug software or by the development
>>     interface.” This implies GDB will be handling these values and CDM
>>     module will transfer those values to the actual debug registers over
>>     debugging signals, right? If yes, then should I be concerned about
>>     how GDB set those values?
>>
>
> yes. You don't need to be concerned exactly how GDB handles these values,
> since you're building a "transparent" interface". What data is being
> transferred through it isn't important at this point.
>
>  4. Mapping all the registers to 32 bit OSD register will be much
>>     better. There will not be any issue in any read or write operation.
>>     So, I will update the specification accordingly. That would mean I
>>     have to extend
>>     https://github.com/opensocdebug/osd-hw/blob/master/blocks/
>> regaccess/common/osd_regaccess_layer.svto
>>     32 bits.
>>
>
> Using 32 bit values makes things easier in the specification, but requires
> you to implement it. Actually not only in hardware, but you also need to
> double-check if the software supports it everywhere. Support exists in some
> parts of the code, but not in all of them AFAIK.
>

So, I will go with the two 16 bit registers specification. For write
operation, we will have an additional update register which must be written
to make sure the data is written correctly. A read operation will take
place only after a breakpoint is hit. This would mean that the core is
stopped and the value of the register should not change. So, there will not
be any trouble with read operation.

Let me sum up the description of CDM module. In CDM module, each or1k debug
registers is mapped into two 16 bit wide OSD register. Now,  I can set
breakpoints in my program using GDB. Every time, a breakpoint is to be set
up, GDB asks for register access. This is accomplished using
osd_regaccess_layer. Now, the address of the breakpoint is loaded in the
module debug registers. This value is transferred to or1k debug registers
over debugging signals. The program is executed. Once a breakpoint is hit,
an event is generated by the CDM module. The CPU is stalled. The control is
passed to the GDB. Debugging of the program takes place.

CDM module will receive the information from GDB and transfer the values to
or1k and vice-versa. The module is not responsible for setting up the
values of debug registers or determining when/how a program counter matches
with the breakpoint address. All these issues will be handled internally.
Now, while generating events, the only event in CDM module will be
"BREAKPOINT HIT". I understand that as in the case of CTM module
<http://opensocdebug.readthedocs.io/en/latest/02_spec/07_modules/ctm/datainterface.html>,
we will have an event packet "Breakpoint hit" to notify the debugger when a
breakpoint is hit. The content (payload word) of this debug packet could be
the number of which breakpoint is reached. Should we have any other detail
in the event debug packet?


Thanks
Shivam Aggarwal
2016195


>
>>
>> Thanks
>> - Shivam Aggarwal
>>
>> On Sat, May 5, 2018 at 7:43 PM, SHIVAM AGGARWAL <shivam16195 at iiitd.ac.in
>> <mailto:shivam16195 at iiitd.ac.in>> wrote:
>>
>>     Hi
>>
>>     I have opened a PR: https://github.com/opensocdebug/osd-doc/pull/8
>>     <https://github.com/opensocdebug/osd-doc/pull/8>
>>
>>     Please take a look whenever you get some time.
>>
>>     Thanks
>>     *- Shivam Aggarwal*
>>
>>     On Fri, May 4, 2018 at 2:21 AM, Philipp Wagner
>>     <philipp.wagner at tum.de <mailto:philipp.wagner at tum.de>> wrote:
>>
>>         Hi,
>>
>>         Am 03.05.2018 um 22:26 schrieb SHIVAM AGGARWAL:
>>         >     - Start working on a PR containing the specification for
>> this module.
>>         >         > Currently I am working on the PR. So, I read the
>> complete specification
>>         > for all the other debug modules. I think specification of
>> Memory Access
>>         > Module (MAM)
>>          >
>>         <https://opensocdebug.readthedocs.io/en/latest/02_spec/07_
>> modules/mam/index.html
>>         <https://opensocdebug.readthedocs.io/en/latest/02_spec/07_
>> modules/mam/index.html>> will
>>         > be very handy for the implementation. We are supposed to create
>> a Memory
>>         > mapped interface just like the one used in MAM module.
>> Debugging signals
>>         > will be used for system interface.
>>         The MAM is actually pretty special in a way that most of its
>>         functionality is not register mapped but packaged in special
>>         events. But
>>         still the register mapped functionality
>>         (http://opensocdebug.readthedocs.io/en/latest/02_spec/07_
>> modules/mam/dbgregisters.html
>>         <http://opensocdebug.readthedocs.io/en/latest/02_spec/07_
>> modules/mam/dbgregisters.html>)
>>         of the MAM (like any other debug module) can serve as a good
>>         starting point.
>>
>>         > I will share the complete specification as per my understanding
>> by
>>         > Friday night IST.         >         > Just one doubt, should I
>> write the specification in .rst format or in
>>         > Google docs? Which one will be more better?
>>
>>         Take the rst of an existing debug module as starting point (i.e.
>> the
>>         structure, how to lay out the register mapping tables, etc.) and
>>         modify
>>         them to contain your specification text.
>>
>>         Once you're happy with the text, open a PR for further discussion.
>>
>>         Philipp
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180507/b4ac1cc6/attachment.html>


More information about the OpenSoCDebug mailing list