Patches sending and applying through mail from terminal

The task assigned was to research the way in which patches can be formatted, send and then applied all directly from git via email. I had to find out the way in which this is to be done. Apparently this is the way in which patches are used in the official circles.

Sending patches from mail

I explored various tools for sending and receiving mails locally from the terminal for the purposes of using them for git send-email.

Binding the device to the driver

Binding is the process of assigning a piece of hardware to a piece of software. The USB dongle I was using today when plugged into the Linux machine was getting picked up by the other USB modules running in the system. What I wanted was for it to be picked up by the driver module that I wrote. This would be verified by when the init function is called and the corresponding message is shown in the dmesg logs. Somehow the binding was not happenning by itself so I had to do it manually. It involved disabling a couple of USB modules and then re forming some symbolic links.

USB module registeration

As an example and a way to teach my self I registered a demo driver module for USB on the Linux machine.

Testing USB driver and Trying out DK

First of all I tried using DK with the USB dongle for BlueNRG. It worked. The dongle was responding and everything. The format was difficult to understand but still getting the response paved way to two things, one it proves that the USB dongle is working and second it gives a way in which DK can be used.

Next order of business was to test the small USB module I have written for the USB dongle by actually inserting the dongle into the system and checking out what happened.

vhci in buildroot

Based on my previous work with vhci, I was happy with how one is able to test things without actually an adapter in the system. Since the 2089 board also does not have the adapter, I had to include to vhci in it. At least that is what I wished. But as it turned out that buildroot does not have any possible way of including vhci. This made me drop the whole idea.

Enabling Bluetooth in 2089 board

The 2089 board is a beast, at least from the looks of it. I have been told that it is the best board for development considering its awesome debugging support using the ST link debugging utility. The kernel image and rootfs was of course to be prepared using buildroot. And in the rootfs I had to enable the Bluetooth support. The task seemed easy enough but just as I included the packages, the system stopped booting. So there was that.

Virtual HCI

Bluez has this thing called VHCI which basically let's you play around acting like you are using a Bluetooth adapter when actually you are not using any. This is helpful for testing things when you don't actually have the adapter. Today was about checking VHCI out and exploring it.

VHCI

I was assigned this task of exploring what VHCI is and hor it interacted with the rest of the Bluez stacck. But as is the case with most Linux related things, the documentation was hard to understand and there wasn't much coverage online about this. So gathering information and making sense of it all was difficult.

Testing the NFC setup using ddd

DDD is a graphical version of the famous gdb debugger. I had to test using ddd, the NFC setup on the 2089 board. The debugging involved taking traces and checking to see if any errors happen.

Starting things out

Today I tried to use BlueNRG DK. And then started with the 2089 board setup with STMC debugger.

Bluez study

Studied the user tools offered by BlueZ and established a tentative flow of commands from the userspace to the kernel side drivers.

Demo platform driver

Made an entry in the DTS (after learning previously that this is something that needs to be done) and then tested to see if reacted to a demo platform driver. It did.

Kernel build with varied configurations

I was asked to build the kernel for BeagleBone Black with at least five different configurations.

I also continued the study of BlueNRG datasheet.