On Thursday 08 September 2016 21:08:07 you wrote: > I went ahead and reworked http://openocd.zylin.com/1200 and converted all my > code ontop of that. So that's a very brief history why it was done this > way.
I, too, think that was the correct approach. > > Now the question of Aarch32 and Aarch64 handling. I see that those are > different enough that a new aarch64 was created, just like cortex_m as to > cortex_a. Since both cortex_m and cortex_a are riddled with armv7 > assumption and aarch64 is different is quite a few areas like crosstrigger, > register and instruction usage. My intention at the time was to reuse (or > rename) cortex_a.c to be the Aarch32 target, but perhaps that might be too > optimistic since Aarch32 debug is also different enough - it uses thumb2 > instructions etc. When I first saw that I thought it was a mistake in the docs, or that T32 and A32 would at least share some common instructions that allow code reuse. But the instruction encodin is different. Why would ARM do that, it sort of blocks an incremental path of developing debug support for ARMv8. Do you know if there's a method to read registers that is usable in AArch32 and -64 execution states? I'm wondering if AArch32 will require a complete, additional debug implementation. Cache maintenance is another aspect that apparently different in -32 and -64 states. MMU and virt2phys translations is the next. For synchronization, DSB exists in Aarch32 state, but the encoding is different to -64 state. T32 and A64 don't seem to have a common, usable subset. Was your code working in Aarch32 state? BR, Matthias > > David > > ________________________________________ > From: Matthias Welwarsky <matth...@welwarsky.de> > Sent: Thursday, September 8, 2016 2:14 AM > To: David Ung > Cc: openocd-devel@lists.sourceforge.net > Subject: Re: OpenOCD Aarch64 support > > On Wednesday 07 September 2016 21:13:43 you wrote: > > sure > > > > if you require a more general discussion it might be best to cc > > openocd-devel, since I see quite a few people are interested on 64bit > > support. > > Some is just into details of the implementation, some is about broader > topics, so I'll just Cc the devel mailing list from here on. > > Let me fill you in on my current state: > > I've started by rebasing your patch series up to here: > http://openocd.zylin.com/#/c/2747/4 onto the current master branch, to > incorporate the DAP related refactoring that meanwhile went into master. > > Then I looked into merging changes that Pierre Kuo added in between in this > patch: http://openocd.zylin.com/#/c/2523/, which is apparently what also > Peter Griffin of Linaro used to get debugging working on the Hikey board. > > However, I think that 2523 goes too far in certain places, for example by > eliminating all code that discerns between AARCH32 and AARCH64 execution > state of a PE, e.g. when reading registers from the core. I think while > this patch fixes some important aspects of AARCH64 debugging, it breaks > AARCH32 debugging in the process. > > There's also the patch series from Alamy Liu, which also adds on top of your > series, but it's introducing some far ranging changes in the architecture > which I'm quite sure I won't be following. > > Did you ever look closer into 2523 or the Liu patches? What do you think of > them? > > On a broader scope, was there a specific technical reason why you created a > new aarch64 target instread of integrating with cortex_a ? Of course there > are some notable differences, but there is also now a lot of duplicated > code. > > David > > BR, > Matthias > > > > ---------------------------------------------------------------------------- > ------- This email message is for the sole use of the intended recipient(s) > and may contain confidential information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all copies > of the original message. > ---------------------------------------------------------------------------- > ------- ------------------------------------------------------------------------------ _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
