Re: [WIP] Bare-metal register browsing

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

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
>