[FE training-materials-updates] Add a TODO list for the labs

[Thomas Petazzoni]

Repository : git://git.free-electrons.com/training-materials.git

On branch  : kernel-ng
Link       : http://git.free-electrons.com/training-materials/commit/?id=f30e5bcde2eb5ca334af1b2b5316bd7c07faeb89

>---------------------------------------------------------------

commit f30e5bcde2eb5ca334af1b2b5316bd7c07faeb89
Author: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Date:   Thu Sep 12 11:35:30 2013 +0200

    Add a TODO list for the labs
    
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>


>---------------------------------------------------------------

f30e5bcde2eb5ca334af1b2b5316bd7c07faeb89
 kernel-labs-todo.txt |  112 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)

diff --git a/kernel-labs-todo.txt b/kernel-labs-todo.txt
new file mode 100644
index 0000000..9570be9
--- /dev/null
+++ b/kernel-labs-todo.txt
@@ -0,0 +1,112 @@
+Lab - Kernel sources
+
+ * No longer use full tarballs + patches, directly use git clone +
+   create a branch.
+
+ * However, git clone is long, shouldn't we make this lab just do the
+   git clone, and do the exploration of the sources together with the
+   compilation lab? Or we should give the training participants a
+   pre-cloned tree.
+
+Lab - Kernel configuration, cross-compiling and booting on NFS
+
+ * Should be adapted to the BeagleBoneBlack. The main change is the
+   usage of the DTB. Note: the bootloader on the BBB must be updated
+   to be able to store the environment in MMC. Talk with Maxime about
+   this. Also make sure to use the patch that adds the DTB for the BBB
+   itself: using the BB DTB on BBB can burn your BBB.
+
+Lab - Writing modules
+
+ * Not much differences here with the existing lab. Ultimately I think
+   we should remove the thing about the kernel version, but that can
+   be left for another time.
+
+Lab - Linux device model for an I2C driver
+
+ * In this lab, we just add the description of the I2C device in the
+   Device Tree, and create a minimal driver that registers itself in
+   the I2C subsystem. We just verify that the ->probe() function gets
+   called when the module is inserted, and the ->remove() function
+   when the module is removed.
+
+   The module code is in
+   training/resources/solutions/input/nunchuk.c. The Device Tree
+   patches are in
+   training/resources/solutions/omap-serial/0003-arm-beaglebone-add-I2C1-bus.patch
+   and
+   git/training/resources/solutions/omap-serial/0004-arm-beaglebone-add-Nunchuk-device-on-I2C1.patch. Do
+   *not* add the pinmuxing for now, it is done in another lab.
+
+Lab - Communicate with the Nunchuk over I2C
+
+ * In this lab, we add the pinmuxing to make the I2C bus really work,
+   and then we add a little bit of code to read the I2C registers of
+   the Nunchuk to check the button status. So maybe something like in
+   ->probe(), dump the value of the register. So the participant can
+   load the module, see the value of the register to find out that the
+   button is released. Then, unload the module, and reload it while
+   the button is pushed, and see the value modified.
+
+   Add a reference of the Nunchuk register layout.
+
+Lab - Expose the Nunchuk functionality to userspace
+
+ * Now we bring the 'input' subsystem stuff into the mix (see the
+   existing nunchuk.c). We only report the events related to the
+   buttons C and Z. As a "going further" step, we could add the
+   joystick events.
+
+ (this is the last lab on the nunchuk, the next labs are going to use
+ the UART)
+
+Lab - Minimal platform driver and access to I/O memory
+
+ * Modify the Device Tree to add an UART description, add the
+   pinmuxing entries, a minimal driver with a ->probe(), that does an
+   ioremap() and output one character on the UART.
+
+   Note: we can remove all the complexity of SSH + netconsole, since
+   we're using the second UART.
+
+   Note: some basic code is in
+   training/resources/solutions/omap-serial/omap-serial.c. The Device
+   Tree files to use UART3 and UART5 are in the
+   0005-arm-beaglebone-add-UART3-device-with-feserial-driver.patch and
+   0006-arm-beaglebone-add-UART5-device-with-feserial-driver.patch
+   patches. For now, only use two UARTs (the one for the debug, plus
+   the one we write the driver for). We will add a third UART later
+   on.
+
+Lab - Output-only serial port driver
+
+ * A bit like our previous character driver lab, but uses the misc
+   subsystem.
+
+   Add the third UART, so that the participant can see his ->probe()
+   function called twice and use two different UARTs with his driver.
+
+Lab - Sleeping and handling interrupts in a device driver
+
+ * Very similar to the lab we already have, just adapted to OMAP. See
+   the code in omap-serial.c to see how to set up interrupts and so
+   on.
+
+Lab - Locking
+
+ * Same lab as today, just ported to the BBB.
+
+   It would be good to improve it to really expose a locking
+   problem. Here is an idea: in the transmit function, we do a loop to
+   wait for the transmit FIFO to be empty, and then we send the
+   character. We introduce a delay between the two things, with
+   mdelay() or something like this. Then, from userspace, two
+   applications are running, one write ABCDEFGHIJK continuously, the
+   other one 0123456789 continuously. We should see some bytes "eaten"
+   because there is no synchronization on the transmit side. Adding a
+   spinlock should exhibit that all the characters are properly seen.
+
+Lab - Investigating kernel faults
+
+ * Same lab as today, just ported to the BBB.
+