User:Lesterwm

From eLinux.org
Revision as of 10:07, 19 May 2011 by Lesterwm (talk | contribs) (Labs)
Jump to: navigation, search


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
Done
Chapter 5
Done
Chapter 6
Done
Chapter 7
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? git add <file>
  2. How do you view staged and unstaged changes? git diff
  3. How do you view comment history? git log
  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? git add <file>; git commit --amend
  5. How do you unstage a file? git reset HEAD <file>
  6. How do you unmodify a file? git checkout -- <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: Done
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:
  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 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 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 Hello.tgz
  9. Modify hello.c to pass the major device number in as a parameter during insmod. Done. See hello.c in Hello.tgz

Optional: Stretch time, I though these would be easy, but after reading up on them, they look rather involved.

  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.
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;
}
Lab 09
Status: Not Started
Observations:
Answers:
Lab 10
Status: Partially 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: