|
Problems |
|
Along the course of the development process we encounter a number of problems, some we solved some we didn't and here we list the most relevant of those.
1 - We are beginner linux users. This makes even the simplest problems drag for hours in comparison with a solution that would take seconds to an experience user. The most annoying example is taking a hour and a half to learn how to extract a tar/bz2 file.
2 - The lack of computer to test and run the program. Due to our groups schedule during the week, meeting has been a difficult task and since only one of the members had a computer with a usb port, the problem increased. This wouldn't be much of a problem if not for the Mandrake Linux incompatibility to this computer mother board.
Again, being beginners at this, we took precious time trying to solve this problem, mostly through the night until someone at a Mandrake forum proposed a solution. We discovered that another member's computer's motherboard had USB capability, but didn't have the appropriate port. Luckily we had such device and we could use the computer for the development.
3 - The linux distribution we installed on the xbox didn't include the source codes and when we tried to overwrite the file structure with the file structure in the rootfs_uclibc_devel.tar.bz2 it caused the installation to brake. We had to reinstall it again, luckily we had a CD-RW with the boot image at hand, in case something like that happened. To this day we have not solved this problem.
Note: To install the Source codes on the Linux Distribution for the Xbox, Jukka Aho (from xbox-linux-users), and Ivan Hawkes (from xbox-linux-devel) recommended following the se steps. This haven't been tried, because we couldn't establish an internet connection for the xbox. Ivan Hawkes recommended trying to Patch the 2.4.20 kernel and recompiling, though he warned us there are still some bugs in the patch. The Patch can be found here, and can be sent to the xbox via SSH.
Note: This steps will make the patched source code compilable. As said by Ivan Hawkes from xbox-linux-devel mailing list.
1. There is a binary file that you will need
from the
CVS. It is called
drivers/net/nvnet/nvnetlib.bin. You will need to copy this file into the
same location in your kernel sources prior to
compiling them.
2. The Makefile for the compressed image needs
a comment taken out to allow misc.o to build. Go to /usr/src/linux-2.4.20/arch/i386/boot/compressed/
(or wherever you placed your kernel source) and
edit Makefile. Take out the comment (#) on the line that looks like this:
4 - After the meeting with the professor we realized our approach would be very difficult to achieve. Turns up we did not have to worry about error checking or fitting the bluetooth driver to work with a socket architecture. Instead we only need to send the data packets assuming there's going to be a program running in the other machine, that will intercept these data packets. On this approach, it makes more sense working from the bottom-up, since the commercial protocol stacks use error-handling and multi-hardware compatibility function that we don't need.
However we didn't waste everything. Through our process of viewing various examples we could take a hint on the major methods of connections and USB commands. We understood a little about USB drivers and some bluetooth functions. What we need to do is start experience with simple codes and simple drivers, and build the bluetooth driver viewing manufacture manuals, to know what commands does the device understand and how it reacts.
5 - After extensive research on the previous approach we came to the conclusion that our bottom-up approach might be more work than we can handle. Since the lower hci layer was already done for the bluez and implementing the hci core was a hard work in itself we then switched our approach so we could work on a higher level, avoid ing the immense work.
6 - The code provided by Billo did not, at first, worked. We had to substitute some old files he took from an old bluez distribution for new ones. And after those modifications it worked, but only on these kernels: 2.4.18 (Red hat distro) and 2.4.21 (Mandrake Distro). Although it's reasonable to say that, for every kernel we were going to run the application, we had to use the hci_usb.c and hci_usb.h from that distribution, otherwise it accused various errors when compiling. On the xbox there was not a compiling error, but when installing the module hci_usb_billo , it showed this message :
root@xbox:/home/dev_driver/billotooth#
insmod hci_usb_billo.o
this module is just slightly modified compared to the original hci_usb function, only some function names are different. Since it worked on those kernels mentioned it should have no problem working on the xbox, since it's kernel is 2.4.20 basically. This wasn't the case though, but someone at the xbox-linux-devel list said that the solution probably lies in compiling the kernel. Which we just recently did, but have not tested it properly .
Note: After we compiled the kernel and set the new boot image, the problem didn't go way. It accused the same messages. So right now, we're forced to abdicate from using the xbox for this project, since we do not have much time and the main goal is to develop a bluetooth driver. However we believe this problem is somewhat related to the semaphore.c file and the spinlock functions. Either we did not set some options right on the kernel compilation or this part of the kernel instruction, which is hardware specific, was not implemented for the xbox, architecture. However we have reasons to believe that the xbox would be compatible with a typical i386 architecture, since it's a Pentium III(Celeron). |