ECEN5013-Homework 3 Solved

[Problem 1] Set up BBG ethernet networking
Modify your BBG configuration using Buildroot to enable ethernet networking with your host.  Enable the packages for DHCP  as well as SSH connectivity (e.g. Dropbear) to allow “scp” copying of files from  Add an ethernet configuration file as a build image overlay that is properly placed in the BBG rootfs to enable DHCP IP addressing on the ethernet interface as a part of booting the BBG.  

. 

 [Problem 2 -] Remote debugging your application with GBD  
Write/port, compile and add your own application (e.g. from Assignment 2 Problem 2) out-of-tree from the Buildroot Linux directories, yet using the Buildroot target tool chain.  Make sure the symbols haven’t been stripped.  Let’s run it on the BBG using GDB and exercise debugging skills with it.  

Next set up your BBG and host for remote debugging. We’re going to use Buildroot (i.e. make menuconfig) to configure and rebuild the BBG target Linux image as well as create host executables so you can do rudimentary remote command-line debugging of code running on the BBG. This method will utilize the ethernet interface for debugging connectivity.

  

Figure 1 - Recommended GDB connectivity The high-level items needed via Buildroot are:

•        Enable running GDB on the host

•        Enable inclusion of GDB Server on the target

•        Enabling debugging with symbols

Besides our MELP textbook, utilize the GDB manual for assistance in executing remote debugging commands. Key points to consider are SYSROOT settings to allow the host access to code symbols and compiling the target code to include them.  

On the BBG console via the serial cable (or ssh to the BBG in another terminal), start gdbserver without supplying an initial command to run or process ID to attach by using the ‘--multi’ command line option.  root@bbg# gdbserver --multi comm & 

Note: “comm” is the IP address:socket# and the “&” at the end of the command line to put the process in the background and allow you to continue to use the console command line.

Next, start GDB on your host, then using a series of GDB commands connect the host to the BBG target, configure the session, push the program you want to debug, and start debugging!  

 

After manually confirming the commands necessary to set up and begin your debug session, demonstrate initializing the host GDB configuration to save some typing by capturing the commands into a gdbint file and adding a “-x gdbinit” as a parameter to your host GDB command.  

 

 

 Start the host GDB session with the program name to debug

1)     Show the host commands connecting to the target  

e.g. (gdb) target extended-remote 192.168.0.8:5555

2)     Pushing your out-of-tree executable to the target  

e.g. (gdb) remote put …

3)     Select the file to debug. This should be set to the filename on the target system.  

e.g. (gdb) set remote exec-file filename

4)     Set breakpoints (e.g. main and others) and any other commands necessary, then run your program

5)     Single stepping through your code and continuing execution

6)     Manually showing (print) variable values at the command line

7)     Capture the “console” printouts from the BBG output of your program.

 

For the future, now that you have exercised the GDB command line basics you can download and set up DDD (a GUI) or perhaps Eclipse IDE to run the GBD remote sessions, as mentioned in MELP.  

 

[Problem 3] Create a Kernel Module
Create your own “external” (not in the tree) kernel module that use a kernel timer to periodically wake up (fire) every 500msec by default. Each time the timer wakes up you should call a function that prints to the kernel log buffers

•        Your name  

•        a count of how many times the timer has fired

 

Declare a statically allocated variable to track this count in your callback function.

  

Your kernel module also needs to take two input parameters, your name and the timer count time in seconds. The parameters should be settable at the installation of the module (E.g. sudo insmod myTimerModule name=”Nikhil” period=30) or via input parameter with module configuration files.  

 

To create/initialize a timer, look for the kernel timer functions:

•        void init_timer (struct timer_list * timer); 

•        void setup_timer (struct timer_list * timer,      void (*function)(unsigned long),unsigned long data); 

 

Be sure to add a callback, modify and/or delete your kernel timer appropriately:

•        void add_timer (struct timer_list * timer); 

•        void mod_timer (struct timer_list * timer, unsigned long expires); 

•        int del_timer (struct timer_list * timer); 

 

Confirm that your module has been loaded by running the command on your system:

$ lsmod | grep module-name 

$ modinfo module-name 

 

 

 

[Problem 4] Data Structures
In this problem pretend your new job is supporting an animal ecologist and process data she has provided you. Although this processing would be better implemented as a user-space application, we’ll use it as a chance to explore Linux data structures and operations.  

 

The objective of this exercise is to create animal-type “sorting” functions in a Linux kernel module. Based on command line (or .conf file) parameters for initialization at module insertion, it will construct and initialize 2 internal lists using the Linux kernel data structure definition, constructs and macros. (e.g.

lists.h)

 

The module is defined with a seed static array of 50 animals types (“frog”, ”spider”, “shark”, “frog”, “elephant”, “fish”, “toad”, etc.) of your choice to be processed during initialization of the module. Note some types should be repeated multiple times in the seed. Process this seed array into two sets:

 

•        An “ecosystem” set of all unique animal types, with duplicates removed. Each type should have associated count of occurrences that they appear in the seed array.  

•        A filtered “list” of animal “types of interest” based on the module input parameter(s).  Filter options should be none, either or both:

o Animal type explicit (e.g. animal_type=”frog” o Count_greater_than (e.g. count_greater_than=2)

 

Your code should dynamically allocate memory used to construct “nodes” for each set and deallocate it upon removal of the module.