Re: [WIP] Bare-metal register browsing

[Vladimir Prus <vladimir.prus@gmail.com>]

Yao,

On 6/4/2015 5:38 PM, Yao Qi wrote:
> Vladimir Prus <vladimir.prus@gmail.com> writes:
>
>> Maybe my patch can be modified to not introduce a new target object, after all. We can use:
>>
>>     <group name="io" target-object="memory">
>> 	<group name="UART2">
>> 		<reg offset="0x4000e030" .../>
>>          </group>
>>     </group>
>>
>> to describe memory-mapped io registers.
>>
>> It sounds like this should be possible to implement. What do you
>> think?
>
> That is fine to me, but I am not sure the meaning of
> target-object="memory" here?  Does this mean this group of registers are
> mapped to memory?

It's a bit more generic - it means that to obtain values of any register
in this group, GDB should perform qXfer of the specified target object
and annex, using register's offset. Memory is the most typical target object,
but in our case, we had other sorts of registers, so I'd prefer the design to
not lock us into memory-mapped registers.

> Does "offset=0x4000e030" mean this register is mapped
> at address 0x4000e030?  If the answers of both questions are yes, is
> target-object="memory" still necessary?  Without it, we can still define
> a group of memory-mapped registers like:
>
>   <group name="io">
>       <reg offset="0x4000e030" name="UART1_1">
>       <reg offset="0x4000e034" name="UART1_2">
>       <reg offset="0x4000e038" name="UART1_3">
>   </group>
>
> and we may even can define a group of normal registers and memory-mapped
> registers, (even it is not likely in practise)
>
>   <group name="io">
>       <reg offset="0x4000e030" name="UART1_1">
>       <reg offset="0x4000e034" name="UART1_2">
>       <reg name="UART1_3">
>   </group>
>
> In this case, UART1_1 and UART1_2 are memory-mapped, while UART1_3 is
> not.  IMO, memory-map-ness is an attribute of each register instead of a
> group, so better to define such attribute on each register level.

It is possible in theory, but I think it has two drawbacks.

First, I think specifying target object is more explicit (and therefore better
than implicit, especially for machine-oriented format) and more generic, as it allows
us to use other target objects.

Second, implementing such mixed registers group is extra complexity, and we did
not find any need for that in practice.

May I suggest we start from a simple use case, where an alternative access mechanism
can only be specified for a top-level group, and it's explicitly specified by
target-object attribute? Should the need arise for mixing differently-accessed
registers inside one group, that can be implemented later with extra code.

>> Two questions:
>>
>> - Is 'group' ok, or 'register-group' would be more clear? We found that the size of these XML
>> files can be sometimes a problem
>
> I don't have preference here.
>
>>
>> - I'd propose that 'target-object' and 'annex' attribute are only allowed for top-level 'group' element,
>>    and not for top-level 'reg' or nested 'group' element, to make implementation simpler. Is that fine?
>
> You have to explain the meaning of target-object and annex first and
> what are the possible values of them.
>
> My last concern is about the testing of these new things in target
> description.  We need some test cases that people can run in their own
> dev env, without involving setting up OpenOCD/JTAG probe/embedded boards.

That's a valid concern. I was using a particular board with USB interface, so did not need a probe,
but even that is not trivial to setup or automate.

If we were to test on a regular computer, I suppose the only way is to have some variables in a C program,
determine their addresses after debug session start, and generate target XML dynamically from that?

- Volodya