Specifications

the USB port appear to software as a standard (old fashioned) RS232 serial port. We can then set up QEMU so that one
of the emulated serial ports on the virtual ma chine maps to the emulated serial port connected to the Tux Controller.
Your tasks for checkpoint 2:
1. Enable the device driver to control the LEDs on the Tu x controller
2. Enable the device driver to r eport w hen buttons ar e pressed and released
3. Handle device resets correctly
4. Enable reading the LED state from the Tux controller.
5. Enable control of the game using the Tu x controller (support keyboard input simultaneously).
6. In the game, enable the up/down/left/right buttons on the Tux controller to do what the arrow keys do o n the
keyboard.
Remember, the Tux driver is expected to work with A N Y user-level program. This means you will not receive full
credit if you do not impleme nt all ioctls de scribed in th is document even if the game does not make use of them.
Set up instructions:
1. Remember to use SVN or save a current version of your code as a backup.
2. You no longer need to compile the entire linux kernel, so you no lo nger need to boot your compiled kernel.
To prevent your compiled kernel from running, right c lick on “test
debug.lnk” shortcut, go to properties a nd
remove the -kernel ...
bzImage from the target line.
3. Enable your test machine to make use of the serial port (named COM#) corresponding to the Tu x c ontroller. To
check which COM number the Tux controller is currently connected on: Go to Start -> Devices and Printers ->
right-click on FT232R U SB UART -> Hardware tab -> USB Serial Port (COM#) where # should be less than
10. If it is higher, call a TA bec ause it will no t work with QE MU. Right click on “test
debug.lnk” shortcut, go to
properties and add -serial COM# to the end of the target line. This connects the Windows COM# port to the
Linux ttyS0 serial port. Note: Only your test ma c hine will be able to com municate with the Tu x controller with
this setup. Although you can also add th is option to your devel machine, you can only have one virtual ma chine
use the Tux at a time. Therefore, we reco mmend you use the devel machine to compile your c ode and the test
machine to load the kernel module and run the game.
4. Also remove the -S option from the end of the target line This option told qemu to wait until gdb was attached .
In this a ssignment we don’t n eed to start g db u ntil after the kernel is up and running.
5. When you first start your debug machine, a dialog will appear asking you fo r COM# Properties. The default
values (Bits per seco nd should be = 960 0, Data bits = 8, Parity = None, Stop bits = 1, Flow con trol = None) will
be correct. Click OK to continue booting your debug machine.
6. If there is no activity for approx imately 2 hours, the Tux controllers will enter a low-power state and turn off the
LEDs. This is intended to prolong the life of the LE D s. Pressing the RESET button will retu rn it to a responsive
state. Be aware o f this if you sit down at a new machine or do not use the con troller for more than two hours.
7. There is a bug in QEM U that m ay cause the test machine to freeze occasionally while using the Tux controllers.
When it is frozen, you will be unable to connect to or interact with it from GDB. If that happens, go to the
QEMU console (ctrl+alt+2), type i 0x3f8 (this will pull bytes from UART like in), press the up arr ow to get
the command again and rep e atedly ente r it several times. Go ba ck to the virtual terminal y ou were in (ctrl+alt+1).
If it is still locked, repeat the steps above until it becom es respon sive.