Fwd: JTAG error with arm-rtems-gdb

Christian Mauderer christian.mauderer at embedded-brains.de
Tue Jun 9 06:36:34 UTC 2020


Hello Mario,

I haven't followed the whole thread. I'm sorry if I maybe ask some stuff
that has been already mentioned.

On 05/06/2020 12:18, Mario Palomares wrote:
> Hi again, i have finally achieved something
> 
> Apparently the problems i had when connecting with GDB derived from the
> OpenOCD version i had installed. I first tried to compile the code from
> source but i got compilation errors and afer a while looking for the
> error i gave up and install the binaries from apt. The versión of apt is
> a little old and gave me some errors with some newer commands so I
> installed the xpack version. That one was up to date but gave me the
> error i mentioned with GDB. 
> In order to apply some patched the openOCD users recommended me i had to
> solve the compilation issue. In the end the problem was that i had the
> RTEMS toolchain path the at the beggining of my PATH env variable. Since
> openOCD requires autotools for compiling, it was using the first
> automake it encunters on that, the one generated by the RSB and that
> automake version is too old for the compilaiton of OpenOCD.  So in case
> anybody tires, add the RTEMS toolchain path at the end.

With the RTEMS toolchain at the end you might have problems compiling
some RTEMS stuff. I normally use a script to set up an environment just
for RTEMS. The script sets the PATH, changes the prompt (that I see it's
an RTEMS-environment) and starts a new shell.

> 
> Don´t know why but the autocompiled openOCD version (even without the
> patches) works well with GDB and the connection is established
> correctly. I have debugged some bare metal programs without problems.
> But there is just one problem/limitaiton, in the case of RTEMS
> executables, i am only able to debug the program with Hardware
> Breakpoints but software breakpoints won´t be established.

I had a simmilar problem once with another chip (ATSAME70 - Cortex-M7).
After quite some time a colleague found out that OpenOCD had problems
with the cache handling. The software breakpoint has been added but the
cache hasn't been invalidated. With that the cached code didn't have a
breakpoint. As a workarround I told openocd to fall back to hardware
breakpoints with the following command in gdb:

    monitor gdb_breakpoint_override hard

> The
> difference bettwen the RTEMS executable and my bare metal programs is
> that i don´t switch back to SVC mode (i stay in HYP mode), and
> obiously i don´t have an operating system. So right know i don´t know if
> there is some kind of  memory protection by RTEMS or if there is some
> limitation in OpenOCD with boards in SVC mode (i have asked there but i
> got no answer).

Maybe ask about cache on the RPi core too.

By the way: Do you try to debug a single core or a SMP application? I
had serious troubles with JTAG (using a J-Link) on the RPi with SMP
applications.

> 
> If anyone knows i would appreciate some help.
> 
> I have seen that Pavel managed to get this debuging environment back in
> 2016 https://devel.rtems.org/wiki/Debugging/OpenOCD/Raspberry_Pi, i am
> wondering if i sould write him directly.

I would suggest to add him on CC. Please use the mail address he already
used for the mailing lists.

Best regards

Christian

> 
> Regards,
> Mario
> 
> El lun., 18 may. 2020 a las 20:49, Mario Palomares
> (<palomares.mario14 at gmail.com <mailto:palomares.mario14 at gmail.com>>)
> escribió:
> 
>     Hi Alan, 
> 
>     I have been asking on the openOCD mailing list and it seems that
>     armv8-a cores on 32 bit mode is currently under development.
>     Actually it is supposed to work but they still have to apply some
>     patches. Right now i am trying one patch they told me, let´s see how
>     it works. I will tell you in case i achieve something.
> 
>     Regarding the building of rtems-libbsd i though it could be compiled
>     for RPI since some GSOC students did that on 2016 (the were working
>     in improving the BSP)
>     https://devel.rtems.org/wiki/GSoC/2016.
> 
>     Regards,
>     Mario
> 
>      
> 
>     El lun., 18 may. 2020 a las 18:38, Alan Cudmore
>     (<alan.cudmore at gmail.com <mailto:alan.cudmore at gmail.com>>) escribió:
> 
>         Hi Mario,
> 
>         Yes, what you said makes sense. I don’t have enough experience
>         with the GDB and OpenOCD to know if your use case can be made to
>         work. Perhaps someone on the raspberrypi.org
>         <http://raspberrypi.org> bare metal forum would know?
> 
>         __ __
> 
>         For your inquiry about libdebugger and rtems-libbsd on the Pi:
>         to my knowledge there is not complete libbsd support for the Pi
>         models yet. I would not expect it to compile right now.
> 
>         __ __
> 
>         Please let us know if you make any progress! If you get openOCD
>         debugging to work with the Pi2 1.2 (A53), it will also probably
>         work with the Pi 3 models.
> 
>         __ __
> 
>         Alan
> 
>         __ __
> 
>         *From: *Mario Palomares <mailto:palomares.mario14 at gmail.com>
>         *Sent: *Sunday, May 17, 2020 12:38 PM
>         *To: *users at rtems.org <mailto:users at rtems.org>
>         *Cc: *Alan Cudmore <mailto:alan.cudmore at gmail.com>
>         *Subject: *Fwd: JTAG error with arm-rtems-gdb
> 
>         __ __
> 
>         __ __
> 
>         ---------- Forwarded message ---------
>         De: *Mario Palomares* <palomares.mario14 at gmail.com
>         <mailto:palomares.mario14 at gmail.com>>
>         Date: dom., 17 may. 2020 a las 18:33
>         Subject: Re: JTAG error with arm-rtems-gdb
>         To: Alan Cudmore <alan.cudmore at gmail.com
>         <mailto:alan.cudmore at gmail.com>>
> 
>         __ __
> 
>         Hi Alan,
> 
>         __ __
> 
>         I have done what you told me (set up the whole environment) and
>         it worked. 
> 
>         First i have to configure the RPI to boot on 64 bit mode (just
>         setting a parameter on config.txt) and later on could establish
>         GDB connection with the gdb the aaarch64 toolchain offers.
>         Gdb-multiarch also worked.
> 
>         __ __
> 
>         It seems the problem is on that amrv8-a53 clusters working in 32
>         bit mode. I don´t know if openOCD has support for amv8-a cores
>         working in 32 bit or if i have to change my configuration file.
> 
>         __ __
> 
>         Does this make sense to you?
> 
>         __ __
> 
>         As an alternative in case this doesn´t work i am currently
>         trying to use the remote debugging through libdebugger but i am
>         experiencing some problems when building the rtems-libbsd
>         library. Should i ask here or create another subject?.
> 
>         __ __
> 
>         Regards, 
> 
>         Mario
> 
>         __ __
> 
>         El sáb., 16 may. 2020 a las 15:58, Alan Cudmore
>         (<alan.cudmore at gmail.com <mailto:alan.cudmore at gmail.com>>) escribió:
> 
>             Hello Mario,
> 
>             Did you try bringing up the complete bare metal environment
>             in the Bare Metal Raspberry Pi 3b JTAG blog entry?
> 
>             I would verify that that environment with the bare metal
>             Aarch64 examples work before trying to get the 32 bit RTEMS
>             binaries to work.
> 
>             It seems like these should work on the Pi2 with the A53 cores
> 
>             https://metebalci.com/blog/bare-metal-rpi3-programming/
> 
>             But the UART example might not work due to the differences
>             between how the uarts are used on the Pi2 and 3.
> 
>              
> 
>             Does the ARM multiarch GDB work with Aarch64? Maybe try the
>             Aarch64 GDB mentioned in the bare metal RPI3 blog entry?
> 
>              
> 
>             Alan
> 
>              
> 
>              
> 
>             *From: *Mario Palomares <mailto:palomares.mario14 at gmail.com>
>             *Sent: *Saturday, May 16, 2020 7:41 AM
>             *To: *users at rtems.org <mailto:users at rtems.org>
>             *Subject: *JTAG error with arm-rtems-gdb
> 
>              
> 
>             I am tryining to debug RTEMS programs on mi RPI2 through a
>             JTAG conexion with OpenOCD. Right now i have the connection
>             correctly established and i can connect through a telnet
>             client. Whenever I try to connect through arm-rtems5-gdb i
>             get the following error
> 
>              
> 
>             warning: while parsing target description (at line 4):
>             Target description specified unknown architecture "aarch64"
>             warning: Could not load XML target description; ignoring
>             Truncated register 16 in remote 'g' packet
> 
>              
> 
>             The configuration file i use for the RPI can be found in
>             this page 
> 
>             https://metebalci.com/blog/bare-metal-raspberry-pi-3b-jtag/. :
> 
>             I can´t use the configuration file proposed here:
> 
>             https://github.com/ppisa/rpi-utils/blob/master/jtag-debug/rpi2/rpi-jt_usb5.cfg by
>             Pavel because my RPI is a RPI2 v1.2 which has the same SoC
>             that the RPI3. If i try Pavels configuration file the
>             connection fails.
> 
>              
> 
>             I have installed gdb multiarch and tried with it but no
>             luck, when i set the architecture to aarch64 i get:
> 
>              
> 
>             warning: Architecture rejected target-supplied description
>             Truncated register 8 in remote 'g' packet
> 
>              
> 
>             Any ideas how to get arround this ?
> 
>          
> 
>         __ __
> 
> 
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


More information about the users mailing list