From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13861 invoked by alias); 4 Jun 2015 14:38:25 -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 12707 invoked by uid 89); 4 Jun 2015 14:38:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f41.google.com Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com) (209.85.220.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 04 Jun 2015 14:38:23 +0000 Received: by padjw17 with SMTP id jw17so30930314pad.2 for ; Thu, 04 Jun 2015 07:38:21 -0700 (PDT) X-Received: by 10.66.193.228 with SMTP id hr4mr70410069pac.48.1433428701539; Thu, 04 Jun 2015 07:38:21 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id ki3sm4066528pdb.74.2015.06.04.07.38.18 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 04 Jun 2015 07:38:20 -0700 (PDT) From: Yao Qi To: Vladimir Prus Cc: gdb-patches@sourceware.org Subject: Re: [WIP] Bare-metal register browsing References: <55349CDB.8010100@codesourcery.com> <864mo5yi1x.fsf@gmail.com> <553E7F2D.6000707@gmail.com> <86lhg2nu3x.fsf@gmail.com> Date: Thu, 04 Jun 2015 14:38:00 -0000 In-Reply-To: (Vladimir Prus's message of "Wed, 03 Jun 2015 22:48:54 +0300") Message-ID: <86h9qno7xo.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00066.txt.bz2 Vladimir Prus writes: > Maybe my patch can be modified to not introduce a new target object, afte= r all. We can use: > > > > > > > > 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=3D"memory" here? Does this mean this group of registers are mapped to memory? Does "offset=3D0x4000e030" mean this register is mapped at address 0x4000e030? If the answers of both questions are yes, is target-object=3D"memory" still necessary? Without it, we can still define a group of memory-mapped registers like: and we may even can define a group of normal registers and memory-mapped registers, (even it is not likely in practise) 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 t= he 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 implemen= tation 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. --=20 Yao (=E9=BD=90=E5=B0=A7)