Re: [OpenOCD-user] Address translation failure while using openocd/gdb load command

[Sholla <hol...@gm...>]

On 11/16/15 20:06, Duane Ellis wrote:
> sholla>> [paraphrased: i can step through the linux kernel, that works]
>
> sholla>> [paraphrased: Now trying to step through a “hello world†app and it does not work - please help]
>
>> Reading symbols from /mnt/builds/rootfs/lib/ld-linux.so.3...(no debugging symbols found)...done.
> That line tells me what is wrong.
>
> Your Hello world application is a “LINUX†application, I know this because GDB is reading the symbol table from the ld-linux.so library
> this library is used by a *LINUX* application, not a bare metal application.
>
> OpenOCD is not (currently) the correct tool for this.
> Instead what you want to use is a “linux gdb server†
> (I say currently, because there are some commercial JTAG debuggers that can debug both the Linux kernel & Apps at the same time, OpenOCD does not have this feature)

Thank you for the detailed response. This cleared all the doubts I had ..

My target board is similar to atmel 9260-ek and hence I had changed the
adapter and the board configuration files and I was wondering whether these
changes were the culprit.


>
> In other words, you have an Linux APP your target needs to boot Linux - your APP requires Linux to run.
> you need to get to the SHELL prompt of your target Linux machine, 
> you then execute the GDB server command on your target linux box and launch your hello world app.
>
> to debug your app your target Linux board will need some means that the GDB server can use to talk to the GDB debugger
> the most common (99.9%) of the time this means you need a TCP/IP connection between your host Linux machine and your target board, a serial port is not sufficent.
>
> Your target Linux distribution should have or come with a GDB server you should use that instead.
>
> =====
>
> So what’s going on here?
> 	OpenOCD is a bare metal debugger - by bare metal, it means there is no operating system controlling the target.
> 	There is no operating system that controls ‘single step’ - or captures the CPU registers after each instruction step.
> 	Instead, OpenOC does this - via the JTAG (or SWD) interface
>
> 	OpenOCD emulates a GDB server and speaks the GDB server protocol.
>
> When you want to “remote debug†a Linux application (which is what you seem to have) you run an application (typically called GDB SERVER)
> 	The GDBSERVER on the target linux platform uses the “man 2 ptrace†Linux interface
> 	See:  http://linux.die.net/man/2/ptrace
>
> What the LINUX GDB server does - is this: 
> 	It opens a socket connection and waits, you connect to the socket via GDB’s remote command.
> 	Your debugger (GDB) sends various commands - for example SINGLE STEP over the TCP/IP connection
> 	The GDB server uses the PTRACE_SINGLESTEP  call to perform an instruction single step.
> 	The Linux operating system then manages the single step process.
> 	
> 	There are others, for example GDB can send a “read memory†packet, or a “write memory packetâ€
> 	The GDB server converts the packet into various PTRACE calls.
>
> In contrast - the OPENOCD GDB Server for ARM7M (i.e.: Cortex M3) - does this:
> 	Reference: ARM Document: ARM DDI 0403D, Section C1.5.1
> 	In short: There is a hardware register called DHSCR (Debug Halting Status And Control Register)
> 	In that register there is a bit that controls single stepping.
>
> 	OpenOCD uses JTAG (or SWD) and the ARM DAP to read/write these bits in the DHCR register.
> 	In the end, the CPU performs the single step.
>
> 	Likewise, OpenOCD converts the Read/Write memory packets into various JTAG/SWD operations to read/write target memory
> In summary:
> 	In the OpenOCD GDB SERVER case, there is no operating system running on top of the “bare metal†of the chip
> 	In contrast, the Linux case there is an operating system between the metal and the app being debugged.


In linux virtual memory addresses in an application depend on the per-process
page tables. But the openocd manual also mentions physical/virtual addresses,
so this is a gap I need to understand.


Thanks again.

> 	It is quite a different process
>
> =======
>
> If what you want is a stand alone “hello world†application that does not run on top of Linux, then you are linking your program and writing your program the wrong way.
>
> A bare metal program - has a body of code called “the startup code†which needs to:
> 	1) Configure the hardware at hard reset -
> 		This includes setting the CPU stack pointer
> 		Turning on the clocks, programing the PLLs
> 		Initializing the DDR memory (if present)
> 	2) zero-ing memory at startup
> 	3) Initialzing global memory that is non-zero at startup
> 	4) And many other things …
>
> The last thing the startup code does is jump to your applications: “main()†function
>
> I’m only giving a very high level overview here, there is much more to this process, including the way you link your application and the libraries your application uses.
>
> =======
>
> -Duane.
>
>