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

[Duane E. <op...@du...>]

> 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.
> 

often when you are debugging a HLOS (high-level-operating-system) device drivers program a DMA of some type to transfer data.

A good example is a USB driver or a camera driver or a video driver … the transfer buffer is located somewhere in memory.

Under an HLOS (like linux) the apps uses virtual memory for code and data. This can also occur in the kernel space (not required to, but this is possible and some HLOS systems do use virt-mem for the HLOS) In the end, the application or the kernel driver has some byte buffer to transmit (or receive) That buffer is at some virtual address, but to program the hardware the driver requires the physical address.   There are many ways to get a buffer in physical memory, every HLOS does this differently. {Thats beyond the scope of this discussion)

Thus because you are debugging an HLOS Kernel, and perhaps a Kernel Driver … it is often helpful to be able to inspect memory (Hex Dump) - at a virtual address, or a physical address 

Hence, OpenOCD supports phys and virt memory, i.e.: Dumping either type

Sadly - GDB (the debugger) has no concept of PHYS vrs VIRT memory .

that is one of the primary differences between a BARE METAL debugger and an APPLICATION debugger
Remember: GDB is a application debugger, that people have forced to become a bare metal debugger.

there’s really more then just PHYS and VIRT, there is also SECURE (i.e.: ARM Trust Zone), and multiple other types of memory.
If you add a Hypervisor, you have yet another layer of craziness

This is what you get when you purchase a commercial debugger.

-Duane.