TDA4VM: Debug A72-Linux on TDA4 using OS awareness in T32

Hello Pablo,

In scripts I've shared before you can find TRACE32 stop mode debug examples at  ./cmm-tda4_dra829/mpu-a72/onchip_trace/processor_trace/, ex: dra829-evm-linux.cmm.  These work well for kernel drivers and modules.  You will need to make sure your vmlinux is compiled with flags CONFIG_PID_IN_CONTEXTIDR=y and CONFIG_DEBUG_INFO=y.  You should be able to get these by changing a config fragments in the build area.  The resulting vmlinux will go from ~20MB to 100MB+.  The end image code does not change but a lot of code and struct information is included in the object file which the debugger needs.

If you want to do run mode debugging (using TRACE32's GUI to talk to gdbserver) you can do that also.  Using kernel assisted debug is more natural for some things compared to stop mode debugging.  It is possible to use both stop and run mode together.  The PDF set tells how to do this.  For run mode debugging you give an IP address and port to connect to.  The LB distro does come with a working gdbserver binary you can use on the target.  I've found for some distros and versions of GDB it could be hard to find a working build, in those cases the LB binary worked where other paths failed.

If you want to use offchip trace with the Linux kernel on the TDA4VM EVM, you also will need to ensure the signals are routed through the FET mux to the MIPI-60.  Linux by default sets the signal routing to a daughter card.  A DT update will allow it to route properly.

It can be useful to set up to stop just at the kernel entry to setup driver breakpoints.  I'd suggest using the dra829-evm-linux-early-breakpoint-insertion.cmm example for that.  It works well with SD card booting.  If you are debugging modules, then using the awareness pull down at insmod time should work well enough.

Richard Woodruff said:

In scripts I've shared before you can find TRACE32 stop mode debug examples at  ./cmm-tda4_dra829/mpu-a72/onchip_trace/processor_trace/, ex: dra829-evm-linux.cmm.  These work well for kernel drivers and modules.  You will need to make sure your vmlinux is compiled with flags CONFIG_PID_IN_CONTEXTIDR=y and CONFIG_DEBUG_INFO=y.  You should be able to get these by changing a config fragments in the build area.  The resulting vmlinux will go from ~20MB to 100MB+.  The end image code does not change but a lot of code and struct information is included in the object file which the debugger needs.

Hello Richard.

I have compiled with those flags activated. Then I will check, but size is much more big that you said...

Thanks a lot for trace problem, this was in past already considered in: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1192456/j721excpxevm-trace-lines-multuiplexed-with-deserializer-in-jacinto7-j721e-dra829-tda4vm-evaluation-module.f

Thanks a lot for list of documentation. I have asked to spanish Lauterbach provider if license is needed to have run&stop mode.

I will inform as soon as I have results.

Many thanks

Hello Pablo,

Yes, your vmlinux was much bigger than I was guessing.  In my local usages it normally goes from like 20MB to ~120MB.  I suppose it depends on what all is in the build.  Probably your custom system is packed with devices.  Or maybe you are doing something like using LLVM and I'm only used GCC.

You should not need any different licenses to use HLOS debug features.  The typical needed are arch + trace + multi-core.  If your cable has a couple core types you will not need multi-core as its inferred.  Your LB provider will know the details for sure, I'm just commenting on my understanding.

I am in conversations with LB provider to prepare fully run&stop mode.

Thanks for your support

Hello Pablo,

That will enable a lot of debug possibilities. Different usage scenarios will have different effort levels. Kernel driver debugging in a single address space is straight forward, working with kernel modules is a bit more work. There is sometimes a desire to get good user space timing information and effort will scale.  The debugger handles the tricky part with multiple address spaces and associations, but it can be a bit of work to get all the debug friendly objects for all processes/threads and their dynamic/shared libraries. In a really big system focus is required as it all can't be gotten, so you need to use different native tools to locate hot spots, then zoom in and focus using the debugger.  On TDA4 recently I've done more low level then Linux level so I checked what our current devs are doing. They were recommending a few more options past what is in the Lauterbach pdf files (normal debug_info and nokaslr) our team was saying CONFIG_CORESIGHT=n and ARM_CORESIGT_PMU_ARCH_SYSTEM_PMU=n also helps in current kernel.

Hello, Richard.

As per our LB provider explanation, it is needed aditional license for Run mode with no limitation, for what we need is running  T32 with "PBI=GDB". This is useless at all, as we can use GDB from other IDEs for free.

For Stop mode (that would allow debugging Kernel and drivers), it is not needed aditional.

I asked for RUN&STOP that would not need aditional license, and It could be very useful for debug processes User Space with kernel running and for drivers debugging in same instance.

LB is describing this "dual" mode in its documentation (https://repo.lauterbach.com/publications/integrated_run_and_stop_mode_debugging_for_embedded_linux.pdf, https://www2.lauterbach.com/pdf/rtos_linux_run.pdf), but as I found many problems to run it, after asking them, they  (provider) confirmed this mode is not available. 

Did you experiment with it?. Or do you open different instances for GDB and STOP mode?

Many thanks