Tuesday Jan 05 2016
I am seeing some strange timing/performance behavior in Blister that has me baffled. The time required to process a frame with no laser line is extraordinarily long, on the order of 150ms. This should not happen. Any frame with no profile should skip all the edge detection code, resulting in the frame being quicker than a normal frame. I used gdb to verify that the frames are being classified as "no line" but I cannot figure out why it seems to take longer.
I was able to build a Nirvana boot disk that contained the profiling tools (See ) but I was very disappointed in the reports.
My hope is that I can rebuild DbgOut and see if that can help. The last working version was 11.2, last compiled on Jan 14, 2014. The project has lain dormant for two years.
It took about an hour or so to configure git access from my Nirvana VM to my repo server on Tuliny, and due to the monolithic structure of my repo I had to pull down the entire repo. This needs to be fixed, but that is an entirely different project.
The biggest hurdle is building a version of the DbgOut kernel module that will insert into the current Linux kernel. The current state of affairs has improved greatly since 2014, now that I can reliably build kernels and boot disks using yocto.
SetLnx.sh contained lines with a hard-coded reference to the Linux kernel source directory. These needed to be removed, relying on the environment set by the "bitbake -c devshell virtual/kernel" command. The server makefile churned along...
The VerUpdate.pl script is missing, in fact the entire Bin directory was missing. I borrowed a copy of VerUpdate.pl from the Blister project.
Well, that was much less painful than expected. After maybe 10 minutes
of fixing minor things, I have DbgOut11.ko. Let's see if it loads...
root@BLIS-0101A:~/blister# insmod DbgOut11.ko
[ 118.575406] DbgOut11 kernel has arrived...
[ 118.582523] DbgOut11 Server has arrived!
[ 118.586827] DbgOut11 1.2.212 root@blis 20160105154253
[ 118.595770] DbgOutServer: Device 'DbgOutServer' created.
[ 118.606224] Fifo:Create2: Created 32 blocks of 16384 bytes, 524288 total
[ 118.615946] Created 8 trace blocks of 4096 bytes, 32768 total.
[ 118.624470] Trace flush level set to 2620 events.
[ 118.631683] Trace:Create2: DBG_TRACE
[ 118.635436] DbgOut Server creation is complete!
Success!
Trying to build the entire DbgOut suite...
The Linux.mak file was dos-munged. I installed the "dos2unix" package and fixed Linux.mak and OS/LnxUsr/LnxOsUsr.mak. The full build completed without errors. Things are looking promising...
Now I need to remember how to use DbgOut. There should be a test program... ExConsole.
BUG: The output directory for the Server (kernel module) has an extra underscore: "Lnx__armsf_Dbg". This is not actually an extra underscore, it is a missing kernel version. I am not sure how to extract the kernel version from the devshell environment, and will just live with the odd directory name for now.
I found my notes from 2013 under Doc/ full of great build notes,
everything except the instructions on how to run it! I found something
in Readme.txt:
I need to rebuild the Windows relay and viewer projects. MSVS has upgraded from VS2013 to VS2015, forcing the projects to upgrade. This seemed to go smoothly, and I was able to rebuild the relay and viewer projects without problems. I am leaving the Windows driver for later...
Everything ran, but the Windows DbgOutRelay is misbehaving. It is
spewing out "LIVE:" "Forward to Server>" messages, as though someone
is sitting on the RETURN key. The command line that was left in the
Relay project was:
--notimestamp --live 192.168.0.209:5100 --datastore DataStore
I am changing this to (from the ReadMe.txt):
--server LISTENTCP:192.168.0.209 --datastore DataStore --notimestamp
This seemed to work, I now have an Item.bin file of 400KB.
There were some compiler warnings in the Viewer project. VS2015 now flags a warning when implicitly casting -1 to an unsigned int. This is a rather pedantic and unnecessary warning, but it is easy to fix.
WOOT! Success!
My first stumble... The ExConsole project works, but the text from Blister is garbled as though it is expecting unicode and receiving ascii, and there is no trace data. There is a DBGENABLE flag in the options that is 0. I changed it to 1 and there is a segfault in the DbgOut driver while copying a string from the device file.
OK, I copied a fresh DbgOut client library to the Blister project, rebuilt everything, and started Blister under gdbserver. I stepped through the DbgOutStart() function and everything looked fine. I let Blister run and this time I could see the printk's from DbgOut11.ko as it filled trace buffers. This generated an Item.bin of 500KB that looked like this...
I think it only the text from Print() that is being garbled, text printed directly to DbgOut() looks fine.
I ran BlisterV4 directly and it crashed again. I ran it under gdbserver and it worked. I ran it under gdb with no breakpoints, and it worked. DbgOut is very finicky, but it is working.
The procedure for running Blister with DbgOut tracing: