<div dir="ltr">Hello Christian,<div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>-rtos hwthread</div><div><br></div><div>¿Is this the way you are proceeding?</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Mario</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 9 jun. 2020 a las 8:36, Christian Mauderer (<<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Mario,<br>
<br>
I haven't followed the whole thread. I'm sorry if I maybe ask some stuff<br>
that has been already mentioned.<br>
<br>
On 05/06/2020 12:18, Mario Palomares wrote:<br>
> Hi again, i have finally achieved something<br>
> <br>
> Apparently the problems i had when connecting with GDB derived from the<br>
> OpenOCD version i had installed. I first tried to compile the code from<br>
> source but i got compilation errors and afer a while looking for the<br>
> error i gave up and install the binaries from apt. The versión of apt is<br>
> a little old and gave me some errors with some newer commands so I<br>
> installed the xpack version. That one was up to date but gave me the<br>
> error i mentioned with GDB. <br>
> In order to apply some patched the openOCD users recommended me i had to<br>
> solve the compilation issue. In the end the problem was that i had the<br>
> RTEMS toolchain path the at the beggining of my PATH env variable. Since<br>
> openOCD requires autotools for compiling, it was using the first<br>
> automake it encunters on that, the one generated by the RSB and that<br>
> automake version is too old for the compilaiton of OpenOCD. So in case<br>
> anybody tires, add the RTEMS toolchain path at the end.<br>
<br>
With the RTEMS toolchain at the end you might have problems compiling<br>
some RTEMS stuff. I normally use a script to set up an environment just<br>
for RTEMS. The script sets the PATH, changes the prompt (that I see it's<br>
an RTEMS-environment) and starts a new shell.<br>
<br>
> <br>
> Don´t know why but the autocompiled openOCD version (even without the<br>
> patches) works well with GDB and the connection is established<br>
> correctly. I have debugged some bare metal programs without problems.<br>
> But there is just one problem/limitaiton, in the case of RTEMS<br>
> executables, i am only able to debug the program with Hardware<br>
> Breakpoints but software breakpoints won´t be established.<br>
<br>
I had a simmilar problem once with another chip (ATSAME70 - Cortex-M7).<br>
After quite some time a colleague found out that OpenOCD had problems<br>
with the cache handling. The software breakpoint has been added but the<br>
cache hasn't been invalidated. With that the cached code didn't have a<br>
breakpoint. As a workarround I told openocd to fall back to hardware<br>
breakpoints with the following command in gdb:<br>
<br>
monitor gdb_breakpoint_override hard<br>
<br>
> The<br>
> difference bettwen the RTEMS executable and my bare metal programs is<br>
> that i don´t switch back to SVC mode (i stay in HYP mode), and<br>
> obiously i don´t have an operating system. So right know i don´t know if<br>
> there is some kind of memory protection by RTEMS or if there is some<br>
> limitation in OpenOCD with boards in SVC mode (i have asked there but i<br>
> got no answer).<br>
<br>
Maybe ask about cache on the RPi core too.<br>
<br>
By the way: Do you try to debug a single core or a SMP application? I<br>
had serious troubles with JTAG (using a J-Link) on the RPi with SMP<br>
applications.<br>
<br>
> <br>
> If anyone knows i would appreciate some help.<br>
> <br>
> I have seen that Pavel managed to get this debuging environment back in<br>
> 2016 <a href="https://devel.rtems.org/wiki/Debugging/OpenOCD/Raspberry_Pi" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Debugging/OpenOCD/Raspberry_Pi</a>, i am<br>
> wondering if i sould write him directly.<br>
<br>
I would suggest to add him on CC. Please use the mail address he already<br>
used for the mailing lists.<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> Regards,<br>
> Mario<br>
> <br>
> El lun., 18 may. 2020 a las 20:49, Mario Palomares<br>
> (<<a href="mailto:palomares.mario14@gmail.com" target="_blank">palomares.mario14@gmail.com</a> <mailto:<a href="mailto:palomares.mario14@gmail.com" target="_blank">palomares.mario14@gmail.com</a>>>)<br>
> escribió:<br>
> <br>
> Hi Alan, <br>
> <br>
> I have been asking on the openOCD mailing list and it seems that<br>
> armv8-a cores on 32 bit mode is currently under development.<br>
> Actually it is supposed to work but they still have to apply some<br>
> patches. Right now i am trying one patch they told me, let´s see how<br>
> it works. I will tell you in case i achieve something.<br>
> <br>
> Regarding the building of rtems-libbsd i though it could be compiled<br>
> for RPI since some GSOC students did that on 2016 (the were working<br>
> in improving the BSP)<br>
> <a href="https://devel.rtems.org/wiki/GSoC/2016" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/GSoC/2016</a>.<br>
> <br>
> Regards,<br>
> Mario<br>
> <br>
> <br>
> <br>
> El lun., 18 may. 2020 a las 18:38, Alan Cudmore<br>
> (<<a href="mailto:alan.cudmore@gmail.com" target="_blank">alan.cudmore@gmail.com</a> <mailto:<a href="mailto:alan.cudmore@gmail.com" target="_blank">alan.cudmore@gmail.com</a>>>) escribió:<br>
> <br>
> Hi Mario,<br>
> <br>
> Yes, what you said makes sense. I don’t have enough experience<br>
> with the GDB and OpenOCD to know if your use case can be made to<br>
> work. Perhaps someone on the <a href="http://raspberrypi.org" rel="noreferrer" target="_blank">raspberrypi.org</a><br>
> <<a href="http://raspberrypi.org" rel="noreferrer" target="_blank">http://raspberrypi.org</a>> bare metal forum would know?<br>
> <br>
> __ __<br>
> <br>
> For your inquiry about libdebugger and rtems-libbsd on the Pi:<br>
> to my knowledge there is not complete libbsd support for the Pi<br>
> models yet. I would not expect it to compile right now.<br>
> <br>
> __ __<br>
> <br>
> Please let us know if you make any progress! If you get openOCD<br>
> debugging to work with the Pi2 1.2 (A53), it will also probably<br>
> work with the Pi 3 models.<br>
> <br>
> __ __<br>
> <br>
> Alan<br>
> <br>
> __ __<br>
> <br>
> *From: *Mario Palomares <mailto:<a href="mailto:palomares.mario14@gmail.com" target="_blank">palomares.mario14@gmail.com</a>><br>
> *Sent: *Sunday, May 17, 2020 12:38 PM<br>
> *To: *<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
> *Cc: *Alan Cudmore <mailto:<a href="mailto:alan.cudmore@gmail.com" target="_blank">alan.cudmore@gmail.com</a>><br>
> *Subject: *Fwd: JTAG error with arm-rtems-gdb<br>
> <br>
> __ __<br>
> <br>
> __ __<br>
> <br>
> ---------- Forwarded message ---------<br>
> De: *Mario Palomares* <<a href="mailto:palomares.mario14@gmail.com" target="_blank">palomares.mario14@gmail.com</a><br>
> <mailto:<a href="mailto:palomares.mario14@gmail.com" target="_blank">palomares.mario14@gmail.com</a>>><br>
> Date: dom., 17 may. 2020 a las 18:33<br>
> Subject: Re: JTAG error with arm-rtems-gdb<br>
> To: Alan Cudmore <<a href="mailto:alan.cudmore@gmail.com" target="_blank">alan.cudmore@gmail.com</a><br>
> <mailto:<a href="mailto:alan.cudmore@gmail.com" target="_blank">alan.cudmore@gmail.com</a>>><br>
> <br>
> __ __<br>
> <br>
> Hi Alan,<br>
> <br>
> __ __<br>
> <br>
> I have done what you told me (set up the whole environment) and<br>
> it worked. <br>
> <br>
> First i have to configure the RPI to boot on 64 bit mode (just<br>
> setting a parameter on config.txt) and later on could establish<br>
> GDB connection with the gdb the aaarch64 toolchain offers.<br>
> Gdb-multiarch also worked.<br>
> <br>
> __ __<br>
> <br>
> It seems the problem is on that amrv8-a53 clusters working in 32<br>
> bit mode. I don´t know if openOCD has support for amv8-a cores<br>
> working in 32 bit or if i have to change my configuration file.<br>
> <br>
> __ __<br>
> <br>
> Does this make sense to you?<br>
> <br>
> __ __<br>
> <br>
> As an alternative in case this doesn´t work i am currently<br>
> trying to use the remote debugging through libdebugger but i am<br>
> experiencing some problems when building the rtems-libbsd<br>
> library. Should i ask here or create another subject?.<br>
> <br>
> __ __<br>
> <br>
> Regards, <br>
> <br>
> Mario<br>
> <br>
> __ __<br>
> <br>
> El sáb., 16 may. 2020 a las 15:58, Alan Cudmore<br>
> (<<a href="mailto:alan.cudmore@gmail.com" target="_blank">alan.cudmore@gmail.com</a> <mailto:<a href="mailto:alan.cudmore@gmail.com" target="_blank">alan.cudmore@gmail.com</a>>>) escribió:<br>
> <br>
> Hello Mario,<br>
> <br>
> Did you try bringing up the complete bare metal environment<br>
> in the Bare Metal Raspberry Pi 3b JTAG blog entry?<br>
> <br>
> I would verify that that environment with the bare metal<br>
> Aarch64 examples work before trying to get the 32 bit RTEMS<br>
> binaries to work.<br>
> <br>
> It seems like these should work on the Pi2 with the A53 cores<br>
> <br>
> <a href="https://metebalci.com/blog/bare-metal-rpi3-programming/" rel="noreferrer" target="_blank">https://metebalci.com/blog/bare-metal-rpi3-programming/</a><br>
> <br>
> But the UART example might not work due to the differences<br>
> between how the uarts are used on the Pi2 and 3.<br>
> <br>
> <br>
> <br>
> Does the ARM multiarch GDB work with Aarch64? Maybe try the<br>
> Aarch64 GDB mentioned in the bare metal RPI3 blog entry?<br>
> <br>
> <br>
> <br>
> Alan<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> *From: *Mario Palomares <mailto:<a href="mailto:palomares.mario14@gmail.com" target="_blank">palomares.mario14@gmail.com</a>><br>
> *Sent: *Saturday, May 16, 2020 7:41 AM<br>
> *To: *<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
> *Subject: *JTAG error with arm-rtems-gdb<br>
> <br>
> <br>
> <br>
> I am tryining to debug RTEMS programs on mi RPI2 through a<br>
> JTAG conexion with OpenOCD. Right now i have the connection<br>
> correctly established and i can connect through a telnet<br>
> client. Whenever I try to connect through arm-rtems5-gdb i<br>
> get the following error<br>
> <br>
> <br>
> <br>
> warning: while parsing target description (at line 4):<br>
> Target description specified unknown architecture "aarch64"<br>
> warning: Could not load XML target description; ignoring<br>
> Truncated register 16 in remote 'g' packet<br>
> <br>
> <br>
> <br>
> The configuration file i use for the RPI can be found in<br>
> this page <br>
> <br>
> <a href="https://metebalci.com/blog/bare-metal-raspberry-pi-3b-jtag/" rel="noreferrer" target="_blank">https://metebalci.com/blog/bare-metal-raspberry-pi-3b-jtag/</a>. :<br>
> <br>
> I can´t use the configuration file proposed here:<br>
> <br>
> <a href="https://github.com/ppisa/rpi-utils/blob/master/jtag-debug/rpi2/rpi-jt_usb5.cfg" rel="noreferrer" target="_blank">https://github.com/ppisa/rpi-utils/blob/master/jtag-debug/rpi2/rpi-jt_usb5.cfg</a> by<br>
> Pavel because my RPI is a RPI2 v1.2 which has the same SoC<br>
> that the RPI3. If i try Pavels configuration file the<br>
> connection fails.<br>
> <br>
> <br>
> <br>
> I have installed gdb multiarch and tried with it but no<br>
> luck, when i set the architecture to aarch64 i get:<br>
> <br>
> <br>
> <br>
> warning: Architecture rejected target-supplied description<br>
> Truncated register 8 in remote 'g' packet<br>
> <br>
> <br>
> <br>
> Any ideas how to get arround this ?<br>
> <br>
> <br>
> <br>
> __ __<br>
> <br>
> <br>
> _______________________________________________<br>
> users mailing list<br>
> <a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax: +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div>