VisualKernel .4.0 Beta3 — Multiple Questions

[MST]

Hi,

I’m working/learning (with) VisualKernel for some weeks now. My actual “project” is based on a Raspberry Pi 3B+ and I’m testing multiple options to debug some simple kernel modules on this device. Unfortunately, I have multiple issues/questions.

1. For my first attempts with the Pi kernel debugging I used a simple UART connection to it. The USB UART is directly connected to the Virtualbox VM I use to compile and debug the kernel (modules). The debugging in this configuration basically works but I am unable to see any printk output in the VisualKernel UI. I checked listening to the UART device on the linux VM directly and could see the messages at this point (Pi is booted with “ignore_loglevel” option to assure that this is no issue). I loaded the kernel module manually to “simulate” this situation and not get any error from VisualKernel. What should I do to forward the printk ouput to the VisualKernel GUI? Is this possible in this setup or do I need a direct UART/serial connection to the Windows machine? How to configure this if possible?
2. In addition to that I am trying to use a JTAG connection. I am using an ollimex arm-usb-tiny-h. The Pi is set to “JTAG mode” and I checked to wiring like a thousand time.
   Nevertheless I get an error message when testing the JTAG connection
   “All reported device registers have a value of 0, this typically indicates JTAG/SWD wiring problems. Please double-check your board layout and debug connection.”
   I attached the log.

Thank you very much in advance,
MST

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem, please see the answers to your questions below:

1. VisualKernel intercepts the printk() output by setting breakpoints in the functions responsible for processing of the printk() messages. On some platforms, the optimization level/debug symbol settings would interfere with it. Feel free to attach a gdb log so that we could recheck it.
2. The second issue looks like either your JTAG connection is unreliable, or something prevents the chip from responding to the JTAG commands. If you believe the issue is on the VisualKernel side, please try running OpenOCD and gdb manually. If it works outside VisualKernel, we can help you configure VisualKernel to support this setup as well.

[MST]

Hi,

here is the log for the first issue. The kernel is the default raspian kernel (uname -a output is attached).
Could this be the source of the issue? Remember that I can see the printk output on the UART tty of the linux (compilation) machine (all printk output is sent  via serial0, see attached cmdline.txt). On this machine I could successfully build the kernel image required for debugging within the kernel module project.
I also tried to build a “new”, fully configurable kernel with your toolchain (“New Custom Linux Kernel Project”) but I get an error doing so. The error occurs pretty early in the setup phase during the “preparing build environment” step. I attached the log (CustomKernelCompilation.txt). The issue is in the second last line: the end of the ” arm-linux-gnueabihf-” command is missing when starting the kernel config. Is this a bug in your build script? Missing variable? Or do I have to set a variable myself on the pi?

hope this information helps to solve the first issue,
MST

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks, we have rechecked the debugging log. Indeed, the optimization done by the ARM compiler prevents VisualKernel from properly intercepting printk() calls. It does work fine on x86 and x64 targets, however not on ARM. We will try to address it in the further releases, but won’t be able to promise anything at this point.

Regarding the kernel building, there was indeed a glitch that invoked an incorrect command line. We have fixed it in this build: VisualKernel-4.0.3.2334.msi

[MST]

Hi,

there seems to be another glitch in the updated version. It’s happening at the same line:

KERNEL=kernel7l ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make olddefconfig
/*edit*/
It’s likely an issue of an incorrect directory where the make command is called than a wrong command.
/*end edit*/

Full log is attached.

• This reply was modified 1 year, 9 months ago by MST.

Attachments:

You must be logged in to view attached files.

[MST]

Hi,

I cannot edit my previous post a second time.
I found another issue with the new build when running (debugging) my Pi3B KernelModule project.
The error message given is:
“Debugging failed: Value cannot be null. Parameter name: pane”

Logs for more details are attached.

Attachments:

You must be logged in to view attached files.

[Author]

Posts