using libdebugger

Tue May 5 19:10:38 UTC 2020

Hello Chris,

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

*Debugger set up test*: I'have tried the code you gave me but get the
following error

[CPU:0] rtems-db: remote running
[CPU:0] error: rtems-db: tcp remote: socket: (123) Unknown protocol
[CPU:0] rtems-db: remote finishing

I have searched in the source files and it corresponds to this call:

  ld = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
  if (ld < 0) {
    rtems_debugger_printf("error: rtems-db: tcp remote: socket: (%d) %s\n",
                          errno, strerror(errno));
    return -1;
  }

Am i missing some header file where IPPROTO_TCP is defined ??

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.
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?.
Probably these are some fool questions but i am a little confused with this.

*IP*: I assume that for this i have first to check the ip with raspbian and
the use the same i see there?.

*PRINTER*: 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?.

*JTAG*: 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 (
http://openocd.org/doc/html/CPU-Configuration.html#CPU-Configuration), for
my RPI i needed aarch64. Once the conecction is established when i try to
connects it says

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

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.
I have installed gdb multiarch and tried with it but no luck, when i set
the architecture to aarch64 i get

aviso: Architecture rejected target-supplied description
Truncated register 8 in remote 'g' packet

Do you have any ideas how to get arround this?

*SER2NET: *Sorry, i totally misunderstood the documentation, i thought you
could set up a ser2net daemon on the RTEMS executable.

Again thanks for the info,
Mario

El vie., 1 may. 2020 a las 9:10, Chris Johns (<chrisj at rtems.org>) escribió:

> On 1/5/20 2:13 am, Mario Palomares wrote:
> > Well, really useful information Chris thanks, no worries about the lack
> > of documentation completely understandable.
>
> Thanks.
>
> > Just let me ask you some more questions
>
> Sure, no problem.
>
> > - I´am trying to use it on a raspberry pi 2B, is it currently supported,
>
> I am not sure. Each ARM has a range of differences in what is
> implemented. It depends on the model, arch, implementer, and what they
> configure. For example the TI processor on Beagleboneblack does not let
> software enable the debug hardware via software so you need to add a
> small mod to the board and a complex piece of code runs and uses the
> JTAG interface to enable the bit.
>
> > do i have to change something on the snippet of code you showed me?.
>
> Not the code I showed you. If it does not work it will be deep in the
> ARM backend of libdebugger.
>
> > Note: In the BSP i compiled i have all the debugger header files so y
> > suppose it is supported.
>
> It is available however being functional is different. The ARM is
> experimental.
>
> > - Where do you specify the ip of the GDB server ?
>
> This is the IP address of your board. It is the IP address of the
> network interface on your board.
>
> > - I don´t understand the rtems_printer usage, shouldn´t the debug
> > server output always go to the debug client instead of the
> > stdout/stderr/kernel?
>
> The rtems_printer is an interface where core code can output to an
> rtems_printer object and the supplied interface (object) will handle the
> output. Using stdout means the debug server will output to stdout, or
> stderr and kernel means using printk.
>
> > - This one is just for curiosity. What are the rest of header files used
> > for, the ones in "rtems/debugger/"
>
> <looking> For reference they are ...
>
> https://git.rtems.org/rtems/tree/cpukit/include/rtems/debugger
>
> rtems-debugger-bsp.h:
>   Provide BSP or arch specific support for difficult hardware.
>   For example rtems_debugger_arm_debug_configure() is used on the
>   Beagleboneblack to set up the hardware. These are used in BSPs.
>
> rtems-debugger-remote.h:
>   Remote transport interface. Allow users the ability to add a
>   specific type of transport. Currently TCP is provided but USB,
>   serial of spacewire could be used if someone is keen.
>
> rtems-debugger-server.h:
>   The server. Used to start, stop and manage the server.
>
> > Regarding a hardware based debugging solution i am also using right now
> > JTAG with OpenOCD but i am experiencing some problems. Once
> > the conection is established I can connect thorught telnet but not from
> > GDB, i still have to investigate on my own, but if I finally i can´t
> > solve i will ask here.
>
> Oh OK you have a JTAG connector on your RPi. Nice. There is an option
> somewhere in openocd to enable the GDB server. You then use the target
> command in GDB to connect to it.
>
> > I would also like to ask you about another thing i couldn´t find on the
> > documentation. Apparently there is a way to set a ser2net daemon which
> > enables you to connect to the target console through a telnet
> > connection. As with the debugger i don´t know how to set it up.
>
> The best resource is `man ser2net`. This is only for the serial console.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200505/c3326d99/attachment.html>