From: Yao Qi <qiyaoltc@gmail.com>
To: Vladimir Prus <vladimir.prus@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [WIP] Bare-metal register browsing
Date: Thu, 04 Jun 2015 14:38:00 -0000 [thread overview]
Message-ID: <86h9qno7xo.fsf@gmail.com> (raw)
In-Reply-To: <mknln8$kj9$1@ger.gmane.org> (Vladimir Prus's message of "Wed, 03 Jun 2015 22:48:54 +0300")
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? 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.
>
> 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.
--
Yao (齐尧)
next prev parent reply other threads:[~2015-06-04 14:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-20 6:30 Vladimir Prus
2015-04-24 9:47 ` Yao Qi
2015-04-27 18:25 ` Vladimir Prus
2015-04-27 18:39 ` Vladimir Prus
2015-06-01 18:36 ` Vladimir Prus
2015-06-02 13:00 ` Yao Qi
2015-06-03 19:49 ` Vladimir Prus
2015-06-04 14:38 ` Yao Qi [this message]
2015-06-09 20:50 ` Vladimir Prus
2015-06-11 8:56 ` Yao Qi
2015-06-15 13:51 ` Vladimir Prus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86h9qno7xo.fsf@gmail.com \
--to=qiyaoltc@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=vladimir.prus@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox