From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96306 invoked by alias); 1 Jun 2015 18:36:21 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 96293 invoked by uid 89); 1 Jun 2015 18:36:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 01 Jun 2015 18:36:19 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YzUZG-0004eE-Lu for gdb-patches@sourceware.org; Mon, 01 Jun 2015 20:36:10 +0200 Received: from h86-62-88-129.ln.rinet.ru ([86.62.88.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Jun 2015 20:36:10 +0200 Received: from vladimir.prus by h86-62-88-129.ln.rinet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Jun 2015 20:36:10 +0200 To: gdb-patches@sourceware.org From: Vladimir Prus Subject: Re: [WIP] Bare-metal register browsing Date: Mon, 01 Jun 2015 18:36:00 -0000 Message-ID: References: <55349CDB.8010100@codesourcery.com> <864mo5yi1x.fsf@gmail.com> <553E7F2D.6000707@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <553E7F2D.6000707@gmail.com> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00005.txt.bz2 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 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 > > > > read-sensitive="no" save-restore="yes" type="UART0_UART0CTL"/> > read-sensitive="no" save-restore="yes" type="UART0_UART0LTIM"/> > > > size="32" name="UART3CTL" offset="0x4000f030" read-sensitive="no" > save-restore="yes" type="UART0_UART0CTL"/> > read-sensitive="no" save-restore="yes" type="UART0_UART0LTIM"/> > > > 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: > > > name="UAR2CTL"/> > > > name="UART3CTL"/> > > > > > > > > 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 >