User:Lesterwm

=ECE497 Pages= These are pages that I have created in order to help the current and next class of ECE497 - Embedded 32-bit Linux

ECE497 Networking over USB

ECE497 Modifying Kernel Command Line Parameters

=Final Project= See ECE497 Projecting with Sense

=Status Report=

Listings

 * Chapter 4
 * [[media:Chapter_4_Listings.tgz‎| Done]]


 * Chapter 5
 * [[media:Chapter5Listings.tgz‎ | Done]]


 * Chapter 6
 * [[media:Chapter 6 Listings.tgz | Done]]


 * Chapter 7
 * [[media:Chapter 7 Listings.tgz | Done]]


 * Chapter 8
 * Done, as part of Lab 08

Labs

 * Lab 00
 * Status: Complete
 * Observations: N/A (I already had linux installed)
 * Answers: N/A


 * Lab 01
 * Status: Complete
 * Observations: Using the SPED image, you can't boot your Beagle using USB OTG for power (it throws a kernel panic). This is because the kernel image included on image does not have the necessary USB gadget module built-in (its a dynamic module).
 * Answers: N/A


 * Lab 02
 * Status: Complete
 * Observations: Build.tar.gz is absolutely huge. Is all of that necessary? I find myself building the kernel outside of the OE tree because it is just too complicated otherwise. This is a great lab and one that I kept coming back to, its extremely important to the course
 * Answers: N/A


 * Lab 03
 * Status: Complete
 * Observations: Git is a pretty complicated system! Luckily I have used it in other projects so I was familiar with it coming into the lab. The referenced book is great for beginners.
 * Answers:


 * 1) How do you stage a file?
 * 2) How do you view staged and unstaged changes?
 * 3) How do you view comment history?
 * 4) You've just committed something and realize you meant to have committed one more file. How do you add that file to the commit you just did?
 * 5) How do you unstage a file?
 * 6) How do you unmodify a file?
 * 7) After running the remote -v how do you tell if a site is read only or read/write? If the remove is an SSH URL it is read/write, otherwise it is read only.
 * 8) What's the difference between a lightweight and an annotated tag? A lightweight tag is just a pointer to a specific commit in the git history, but an annotated tag is tracked by git and contains information such as author, date, email, etc.


 * Lab 04
 * Status: Complete
 * Observations: This lab is incomplete, but following its spirit, I configured the kernel to my liking. I had to reconfigure from the default Angstrom configuration when I wanted to get networking and power over USB working, since the USB OTG gadget had to be compiled into the kernel (it can't by a dynamic module). I used gconfig to configure it.
 * Answers: N/A


 * Lab 05
 * Status: Complete
 * Observations: I completed this short lab as part of Lab 08. In that lab I added an Example character device module to the necessary Kconfig file.
 * Answers: N/A


 * Lab 06
 * Status: Complete
 * Observations: I've spent a lot of time on this subject while trying to get static MAC addresses working. I wrote up a wiki article based on what I learned. See ECE497 Modifying Kernel Command Line Parameters.
 * Answers: N/A


 * Lab 07
 * Status: Not Started
 * Observations:
 * Answers:


 * Lab 08
 * Status: Complete
 * Observations: This is definitely my favorite lab. Very well constructed, challenging but not impossible.
 * Answers:

Optional: Stretch time, I though these would be easy, but after reading up on them, they look rather involved. static int hello_open(struct inode *inode, struct file *file) {   /* We can change the logic of this function based on the * minor number of our device */ printk("hello_open: successful opened minor number %u\n",        iminor(inode)); return 0; }
 * 1) The major device number 234 is part of a range of unassigned numbers. What is the range? 231-239
 * 2) What's the new line added to hello_init do? Registers this device driver with the given major number (234) and tells the kernel where to find the required file operation functions (open, read, write, ...)
 * 3) What does mknod do? Creates a file in /dev/ that represents the device with the given major number (in our case, 234)
 * 4) Once your device is running try $ cat /proc/devices. Do you see your device? Yes
 * 5) Convert the example in our text to use the newer method. It's only a couple of additional lines, but you will have to read the book to know how to do it. Done. See hello.c in [[media:Hello.tgz | Hello.tgz]]
 * 6) Modify the scull_load script (call it hello_load) on page 47, of chapter 3, to load your module. Done. See hello_load in [[media:Hello.tgz | Hello.tgz]]
 * 7) Test it with use-hello.c from page 222 of Embedded Linux Primer. Done
 * 8) Write a hello_unload script that will rmmod the driver and remove the nodes in /dev Done. See hello_unload in [[media:Hello.tgz | Hello.tgz]]
 * 9) Modify hello.c to pass the major device number in as a parameter during insmod. Done. See hello.c in [[media:Hello.tgz | Hello.tgz]]
 * 1) How can your driver find what the minor device number is? When the device is opened, an inode reference is passed. There is a macro called 'iminor' which takes an inode and returns the minor number.


 * Lab 09
 * Status: Not Started
 * Observations:
 * Answers:


 * Lab 10
 * Status: Complete
 * Observations: Parts a and b of this lab worked well to reinforce the basics of what I already knew about Makefiles. The Configuro portion (Part c) felt very convoluted and silly. Doing a little research on Configuro did not yield much, but it seems to be a TI only tool. It doesn't seem to be of much help in a typical development environment. Perhaps we should reduce the lab to only parts A and B? Or rewrite it to not use Configuro
 * Answers:


 * 1) In the above gcc command, can you name the target, dependency and command? app.o, app.c, and gcc respectively
 * 2) What does the –c option (from step 5) tell the compiler to do? It tells gcc to not run the linker, only the compiler
 * 3) What is the name of the path to the Linux 86 gcc compiler? LINUX86_GCC
 * 4) What is the name of the path where the Linux 86 tools are installed? LINUX86_DIR
 * 5) Study the .o rule for a moment. Look at the command that contains $(CC). Just after the –c on this line, you should see a $< to indicate first dependency only. And, if you use $^ to indicate both dependencies, gMake will fail. Explain: Because compiler.opt is not a compilable c file
 * 6) Now look at the .x rule. Study the command that contains $(CC). Notice that this time we use $^ to indicate both dependencies. If you use $<, gMake will not produce the proper output. Explain: All of the dependencies are compilable c files, and all are necessary because they depend on each other
 * 7) Did gMake run gcc after app.h was touched (i.e. changed)? Yes, since the modification date was later than the binary, gcc was run


 * Lab 11
 * Status: Not Started
 * Observations:
 * Answers:


 * Lab 12
 * Status: Not Started
 * Observations:
 * Answers:


 * Lab 13
 * Status: Not Started
 * Observations:
 * Answers: