[FE training-materials-updates] Add a TODO list for the labs
thomas.petazzoni at free-electrons.com
Thu Sep 12 11:36:54 CEST 2013
Repository : git://git.free-electrons.com/training-materials.git
On branch : kernel-ng
Link : http://git.free-electrons.com/training-materials/commit/?id=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>
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
@@ -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
+ 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
+ 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
+Lab - Output-only serial port driver
+ * A bit like our previous character driver lab, but uses the misc
+ 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
+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.
More information about the training-materials-updates