This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [WIP] Bare-metal register browsing
- From: Vladimir Prus <vladimir dot prus at gmail dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>, Vladimir Prus <vladimir at codesourcery dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 27 Apr 2015 21:25:49 +0300
- Subject: Re: [WIP] Bare-metal register browsing
- Authentication-results: sourceware.org; auth=none
- Newsgroups: gmane.comp.gdb.patches
- References: <55349CDB dot 8010100 at codesourcery dot com> <864mo5yi1x dot fsf at gmail dot com>
On 04/24/2015 12:47 PM, Yao Qi wrote:>
Vladimir Prus <vladimir@codesourcery.com> writes:
>
> Hi Vladimir,
>
>> The attached patches implement accessing peripheral registers on
>> bare-metal targets. Typically,
>> these registers are memory-mapped, so one can poke at them using
>> memory operations, but it's
>> far from convenient. Also, on some targets the registers might require
>> a custom way of access,
>> which makes things even less convenient.
>>
>> This patch allows target XML to describe 'spaces' - contains of
>> registers, which can be further grouped.
>> Given that descrpiption, GDB allows one to do something like:
>>
>> (gdb) print $io.GPIO_PORTF.GPIO_PORTFDIR
>> $7 = -1
>>
>> to access registers. One can also do
>>
>> (gdb) ptype $io
>>
>> to see top-level register groups in space 'io', and so find the
>> desired register.
>
> What does the xml using 'spaces' look like? A small example would be
> useful. Target description "reg" has already had a component "type",
> can't we extend "type" for memory-mapped registers? I am trying to
> understand how useful it is to add 'spaces' here.
Hi Yao,
Here's extract from an actual file
<space annex="memory" name="io">
<group name="UART2">
<reg bitsize="32" name="UART2CTL" offset="0x4000e030" read-sensitive="no" save-restore="yes" type="UART0_UART0CTL"/>
<reg bitsize="32" name="UART2LTIM" offset="0x4000e098" read-sensitive="no" save-restore="yes" type="UART0_UART0LTIM"/>
</group>
<group name="UART3">
size="32" name="UART3CTL" offset="0x4000f030" read-sensitive="no" save-restore="yes" type="UART0_UART0CTL"/>
<reg bitsize="32" name="UART3LTIM" offset="0x4000f098" read-sensitive="no" save-restore="yes" type="UART0_UART0LTIM"/>
</group>
The full file can be found at https://drive.google.com/open?id=0BzXbGnw_jIF6cThVZHU2T3l0SXM&authuser=0
The space and group elements are not 100% required - it might be possible to instead have something like:
<struct id="UART2">
<field offset="0x4000e030" bitsize="32" type="int" name="UAR2CTL"/>
</struct>
<struct id="UART3">
<field offset="0x4000f030" bitsize="32" type="int" name="UART3CTL"/>
</struct>
<struct id="io">
<field name="UART2" type="UART2"/>
<field name="UART3" type="UART3"/>
</struct>
<reg name="io" type="io"/>
But it seems to me that this overloading of existing concepts might not be perfect:
- Normally, top level 'reg' element are accessed using ordinary packets, so we'd need to special case 'reg' above
- Using 'reg' element to refer to large number of registers, and using 'field' to refer to registers can be
confusing.
- GDB type system does not support 'offset' field for physical address, and unlike space, there is no easy
place to add this information.
So it seems to me that the original syntax is more straight-forward representation of hardware.
Thanks,
Volodya
--
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com
--
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com