This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [WIP] Bare-metal register browsing


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 (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]