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.maude...@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.mari...@gmail.com <mailto:palomares.mari...@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.cudm...@gmail.com <mailto:alan.cudm...@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.mari...@gmail.com> > > *Sent: *Sunday, May 17, 2020 12:38 PM > > *To: *users@rtems.org <mailto:users@rtems.org> > > *Cc: *Alan Cudmore <mailto:alan.cudm...@gmail.com> > > *Subject: *Fwd: JTAG error with arm-rtems-gdb > > > > __ __ > > > > __ __ > > > > ---------- Forwarded message --------- > > De: *Mario Palomares* <palomares.mari...@gmail.com > > <mailto:palomares.mari...@gmail.com>> > > Date: dom., 17 may. 2020 a las 18:33 > > Subject: Re: JTAG error with arm-rtems-gdb > > To: Alan Cudmore <alan.cudm...@gmail.com > > <mailto:alan.cudm...@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.cudm...@gmail.com <mailto:alan.cudm...@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.mari...@gmail.com> > > *Sent: *Saturday, May 16, 2020 7:41 AM > > *To: *users@rtems.org <mailto:users@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@rtems.org > > http://lists.rtems.org/mailman/listinfo/users > > > > -- > -------------------------------------------- > embedded brains GmbH > Herr Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@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. >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
