Re: [WIP] Bare-metal register browsing

Vladimir Prus
2015-06-01T18:36:21Z

Yao,

did you have any further comments?

Thanks,

On 4/27/2015 9:25 PM, Vladimir Prus wrote:
>
> 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
>