<div dir="ltr">Hello Chris,<div><br></div><div>I answered you a couples of day ago but "users" account didn´t get included don´t know why, anyway sorry about that. These are some updates/question I have regarding the last email<br><div><br></div><div><b>Debugger set up test</b>: I'have tried the code you gave me but get the following error </div><div><br></div><div>[CPU:0] rtems-db: remote running</div>[CPU:0] error: rtems-db: tcp remote: socket: (123) Unknown protocol<br>[CPU:0] rtems-db: remote finishing<div><br></div><div>I have searched in the source files and it corresponds to this call:</div><div><br> ld = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);<br> if (ld < 0) {<br> rtems_debugger_printf("error: rtems-db: tcp remote: socket: (%d) %s\n",<br> errno, strerror(errno));<br> return -1;<br> }<br></div><div><br></div><div>Am i missing some header file where IPPROTO_TCP is defined ??</div><div><br></div><div>Also there is something i don´t understand in this process. I have seen that the example you showed me is from the FreeBSD project, i have read that there you port the FreeBSD drivers to RTEMS but i don´t understand how that later on those drivers merge to the RTEMS proyect, because i have seen that the is a libbsd on the RTEMS proyect, so i don`t know if this proyect is an extension of RTEMS or if it is and intermediate for porting capabilities.</div><div>Another thin regarding the same is that the raspberry Pi BSP doesn´t have support for ethernet right now so i don't know how this test could this work. Is that support implemented in the FreeBSD proyect?.</div><div>Probably these are some fool questions but i am a little confused with this.</div><div><br></div><div><b>IP</b>: I assume that for this i have first to check the ip with raspbian and the use the same i see there?.</div><div><br></div><div><b>PRINTER</b>: I still don´t understand the part of rtems_printer, i mean what is the difference between the messages the GDB server send to the GDB client, and the ones the GDB server send to stdout?.</div><div><br></div><div><b>JTAG</b>: I have checked and partially understood which problem i had with the connection between openocd and GDB. Apparently the raspberry pi i bought is a Raspberry Pi 2 v1.2, which means it has the SoC BCM2837 with an ARMV8-A53 (64 bit), exactly the same as the Raspberry Pi3. The RTEMS BSP for Raspberry Pi is only supposedly to work with PI2, since files execute correctly for me (i have even used serial protocols) I assumed there is like a half-potability between RPI2 and RPI3. The problem is that when you configure openOCD, since it is such a low level configuration, you have to specify correctly the hardware underneath. From all the stuff you have to configure the part that affects is where you specify the type of CPU, there you have a list of possible values which refer to different ARM CPU (<a href="http://openocd.org/doc/html/CPU-Configuration.html#CPU-Configuration" target="_blank">http://openocd.org/doc/html/CPU-Configuration.html#CPU-Configuration</a>), for my RPI i needed aarch64. Once the conecction is established when i try to connects it says </div><div><br></div>warning: while parsing target description (at line 4): Target description specified unknown architecture "aarch64"<br>warning: Could not load XML target description; ignoring<br>Truncated register 16 in remote 'g' packet<div><br></div><div>I imagine the arm-rtems5-gdb isn´t compatible with the GDB server openOCD is setting up regarding the hardware description i gave. Quite strange because i have checked the arquitectures de arm-rtems5-gdb supports and there is one that says armv8-a, which i thought would work.</div><div>I have installed gdb multiarch and tried with it but no luck, when i set the architecture to aarch64 i get</div><div><br></div><div>aviso: Architecture rejected target-supplied description<br>Truncated register 8 in remote 'g' packet<br></div><div><br></div><div>Do you have any ideas how to get arround this?</div><div><br></div><div><b>SER2NET: </b>Sorry, i totally misunderstood the documentation, i thought you could set up a ser2net daemon on the RTEMS executable.</div><div><br></div><div>Again thanks for the info,</div><div>Mario</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El vie., 1 may. 2020 a las 9:10, Chris Johns (<<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</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">On 1/5/20 2:13 am, Mario Palomares wrote:<br>
> Well, really useful information Chris thanks, no worries about the lack <br>
> of documentation completely understandable.<br>
<br>
Thanks.<br>
<br>
> Just let me ask you some more questions<br>
<br>
Sure, no problem.<br>
<br>
> - I´am trying to use it on a raspberry pi 2B, is it currently supported, <br>
<br>
I am not sure. Each ARM has a range of differences in what is <br>
implemented. It depends on the model, arch, implementer, and what they <br>
configure. For example the TI processor on Beagleboneblack does not let <br>
software enable the debug hardware via software so you need to add a <br>
small mod to the board and a complex piece of code runs and uses the <br>
JTAG interface to enable the bit.<br>
<br>
> do i have to change something on the snippet of code you showed me?. <br>
<br>
Not the code I showed you. If it does not work it will be deep in the <br>
ARM backend of libdebugger.<br>
<br>
> Note: In the BSP i compiled i have all the debugger header files so y <br>
> suppose it is supported.<br>
<br>
It is available however being functional is different. The ARM is <br>
experimental.<br>
<br>
> - Where do you specify the ip of the GDB server ?<br>
<br>
This is the IP address of your board. It is the IP address of the <br>
network interface on your board.<br>
<br>
> - I don´t understand the rtems_printer usage, shouldn´t the debug <br>
> server output always go to the debug client instead of the <br>
> stdout/stderr/kernel?<br>
<br>
The rtems_printer is an interface where core code can output to an <br>
rtems_printer object and the supplied interface (object) will handle the <br>
output. Using stdout means the debug server will output to stdout, or <br>
stderr and kernel means using printk.<br>
<br>
> - This one is just for curiosity. What are the rest of header files used <br>
> for, the ones in "rtems/debugger/"<br>
<br>
<looking> For reference they are ...<br>
<br>
<a href="https://git.rtems.org/rtems/tree/cpukit/include/rtems/debugger" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/cpukit/include/rtems/debugger</a><br>
<br>
rtems-debugger-bsp.h:<br>
Provide BSP or arch specific support for difficult hardware.<br>
For example rtems_debugger_arm_debug_configure() is used on the<br>
Beagleboneblack to set up the hardware. These are used in BSPs.<br>
<br>
rtems-debugger-remote.h:<br>
Remote transport interface. Allow users the ability to add a<br>
specific type of transport. Currently TCP is provided but USB,<br>
serial of spacewire could be used if someone is keen.<br>
<br>
rtems-debugger-server.h:<br>
The server. Used to start, stop and manage the server.<br>
<br>
> Regarding a hardware based debugging solution i am also using right now <br>
> JTAG with OpenOCD but i am experiencing some problems. Once <br>
> the conection is established I can connect thorught telnet but not from <br>
> GDB, i still have to investigate on my own, but if I finally i can´t <br>
> solve i will ask here.<br>
<br>
Oh OK you have a JTAG connector on your RPi. Nice. There is an option <br>
somewhere in openocd to enable the GDB server. You then use the target <br>
command in GDB to connect to it.<br>
<br>
> I would also like to ask you about another thing i couldn´t find on the <br>
> documentation. Apparently there is a way to set a ser2net daemon which <br>
> enables you to connect to the target console through a telnet <br>
> connection. As with the debugger i don´t know how to set it up.<br>
<br>
The best resource is `man ser2net`. This is only for the serial console.<br>
<br>
Chris<br>
</blockquote></div>