We can use bfin gdbproxy to debug the kernel, as described in:
toolchain:debug:gdbproxy [Analog Devices Open Source| Mixed-signal and Digital Signal Processing ICs]
A more hands on step by step operation sequence looks like following:
1)On host PC, run “bfin-gdbproxy bfin”, you will see information like “waiting on TCP port 2000”. Then leave this terminal alone.
2)Reset the target board, it should run into Linux console, generally we would use the tftp load uImage way to do this during the development, step is identical to running a default uImage.
3)On host PC, open a new terminal, and run "bfin-uclinux-gdb vmlinux", note you must have the generated vmlinux in current path you run this command, and the vmlinux file should be the one generated together with your uImage you booted in step 2.
4)Then you should see a typical gdb command line interface is up, there you can do lots of things following the general gdb rule, it's often something like:
a) target remote:2000 (from here the board should be frozen)
b) b start_kernel (set a breakpoint in kernel function start_kernel, or any other function, lines you want to break )
c) c (target continue to run, and stop at the breakpoint specified in step b)
you can also use more gdb facilities, for example use watch to watch a specific variable, google "gdb usage" for more gdb related facilities and usage.
These two articles give good instruction on using GDB to debug kernel modules.
The Kernel Newbie Corner: What's in That Loadable Module, Anyway? | Linux.com
When adding the Symbol file to gdb, replace this line "add-symbol-file .../gdb1.ko 0xffffffffa00f4000 \" with "add-symbol-file /lib/modules/X.X.X-linux-version/gdb1.ko 0xffffffffa00f4000 \" so that gdb can find your module.