Re: [WIP] Bare-metal register browsing

[Yao Qi <qiyaoltc@gmail.com>]

On 09/06/15 21:49, Vladimir Prus wrote:
> 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.
>

I don't object to it.

>> 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.

If such mixed registers group brings extra complexity in the
implementation, then I am inclined to start from a simple one.

>
> 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?

Yes, that is what I want to suggest too.

-- 
Yao (齐尧)