Fwd: JTAG error with arm-rtems-gdb
Mario Palomares
palomares.mario14 at gmail.com
Thu Jun 18 10:13:57 UTC 2020
Hello Christian,
What you say about cache invalidation problems makes sense, but i am not
sure if that is muy problem since the debug messages give me some kind of
error. Anyway i will ask again and see if someone answers.
In relation to SMP debugging with openOCD i haven´t tried it yet,
nevertheless as far as i know by default openOCD sets one GDB server for
each CPU so not sure how you could debug with one session all cores. I have
seen that openOCD has an rtos support that would let you debug SMP
applications, RTEMS is not in the list of supported RTOS but there is a
generic RTOS that could do the trick
-rtos hwthread
¿Is this the way you are proceeding?
Pavel, i have included you in the thread since i saw you managed to debug
programs on the RPI through JTAG. To sum up all previous messages just say
that right know i have the JTAG conexion established and the GDB attached
to it, but i can only set Hardware Breakpoints, Software breakpoints never
get established, did you experienced this?. Christian suggests there can be
some cache invalidation problems.
Regards,
Mario
El mar., 9 jun. 2020 a las 8:36, Christian Mauderer (<
christian.mauderer at embedded-brains.de>) escribió:
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200618/53d4d0a6/attachment-0001.html>
More information about the users
mailing list