Escolar Documentos
Profissional Documentos
Cultura Documentos
Lab Instructions
Important Notice
Important Notice
Texas Instruments and its subsidiaries (TI) reserve the right to make changes to their products or to discontinue any product or service without notice, and advise customers to obtain the latest version of relevant information to verify, before placing orders, that information being relied on is current and complete. All products are sold subject to the terms and conditions of sale supplied at the time of order acknowledgment, including those pertaining to warranty, patent infringement, and limitation of liability. TI warrants performance of its semiconductor products to the specifications applicable at the time of sale in accordance with TIs standard warranty. Testing and other quality control techniques are utilized to the extent TI deems necessary to support this warranty. Specific testing of all parameters of each device is not necessarily performed, except those mandated by government requirements. Customers are responsible for their applications using TI components. In order to minimize risks associated with the customers applications, adequate design and operating safeguards must be provided by the customer to minimize inherent or procedural hazards. TI assumes no liability for applications assistance or customer product design. TI does not warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, or other intellectual property right of TI covering or relating to any combination, machine, or process in which such semiconductor products or services might be or are used. TIs publication of information regarding any third partys products or services does not constitute TIs approval, warranty or endorsement thereof.
Revision History
August 2012 Revision 1.0
Mailing Address
Texas Instruments Training Technical Organization 6550 Chase Oaks Blvd Building 2 Plano, TX 75023
ii
1-1
Module Topics
Module Topics
Lab 1: Booting Linux .................................................................................................................................1-1 Module Topics..........................................................................................................................................1-2 A. Create a Bootable SD Card .................................................................................................................1-3 C. Boot Linux on the AM335x Starter Kit ................................................................................................1-7
1-2
1-3
ubuntu$ sudo umount /dev/sdb1 ubuntu$ sudo umount /dev/sdb2 ubuntu$ sudo umount /dev/sdb3 Note: your micro-SD card may or may not have a third partition. If there is no third partition, you will get a warning when you attempt to unmount, but this can be ignored. 6. Reformat the micro-SD card. (This step assumes that the device node determined in step 4 is sdb, otherwise replace sdb with the correct node.) ubuntu$ sudo mkdosfs vIF 32 /dev/sdb ubuntu$ sudo partprobe /dev/sdb ubuntu$ sudo dd if=/dev/zero of=/dev/sdb bs=512 count=200 This command will reformat the micro-SD card as a non-partitioned device with the Windows file allocation table (FAT) file system, which is how most new cards would be formatted out of the box. If you like, you can unplug the USB connection to the micro-SD reader and plug it back in so that the PC automounts the new, empty file system in order to verify the erasure. The partprobe command is required because Linux does not automatically re-load the partition table for a device when it is reformatted (or even when the USB device is unplugged and reattached), so in order to make sure that this information is reloaded and therefore that the create-sdcard.sh script will execute correctly, the partition probing application partprobe should be used. The final, optional command dd (dataset definition) will copy zeros from a special file (/dev/zero) into the device node, erasing its contents. A block size of 512 bytes is chosen because it is the sector size of the micro-SD card. It is not necessary that these match, but it will improve efficiency of the copy operation if they do. The count will indicate how many 512B blocks should be erased. 100kB is sufficient to erase the boot partition, which is 72kB in size. You could erase an entire 4G micro-SD card with a count of 8M; however this would require more than 10 minutes to complete. 7. Change into the ~/labs/lab01_boot_linux directory. ubuntu$ cd ~/labs/lab01_boot_linux Note: You can use the autofill feature to make this faster by typing cd ~/labs/lab01 and then pressing the <tab> key. 8. List the contents of this directory. ubuntu$ ls You should see two gnu-zipped (gz) tape archive (tar) files boot.tar.gz and rootfs.tar.gz and also a script file create-sdcard.sh that is actually a soft link to a file by the same name that ships with the software development kit (sdk) installed at /home/user/ti-sdkam335x-evm-05.05.00.00. The MLO, u-boot and uImage files that are archived into boot.tar.gz were taken directly from: ti-sdk-am335x-evm-05.05.00.00/board-support/prebuilt-images The rootfs.tar.gz is a slight modification on the file system provided at: ti-sdk-am335x-evm-05.05.00.00/file system/tisdk-rootfs-am335x-evm.tar.gz
1-4
9. Test the contents of the boot.tar.gz archive. It is a good idea before expanding an archive to test its contents to see what will be written. Lets verify that the archive boot.tar.gz has the boot files we expect to place in partition 1 of the multimedia card. ubuntu$ tar ztf boot.tar.gz 10. Execute the create-sdcard.sh script, being sure to use root permissions via the sudo (switch user do) command. ubuntu$ sudo ./create-sdcard.sh This script creates two partitions on the multimedia card and formats the partitions (vfat on partition 1 and ext3 on partition 2). The partitioning requirements needed for a microSD card to be bootable on a TI ARM device must be precise, and this script guarantees that the partitioning is done correctly. The script will ask some questions, the next steps specify what you should answer. 11. (create-sdcard.sh) Specify device number/node for the micro-SD card. The script will list the devices on the system to which the Linux boot files may be written. You should see something similar to: # major minor size name 1: 8 88 3813376 sdb In particular, the name listed in the final column should be the same as was determined in step 4. There should be only one option, so enter 1 and continue. 12. (create-sdcard.sh) Specify two partitions. A bootable SD card requires two partitions. The first partition contains the MLO, u-boot and kernel image. The second partition contains the root file system (which must be in a separate partition). The create-sdcard.sh script provides the option of creating a third partition. This is because the micro-SD card that comes with the AM335x starter kit boards has a third partition that contains the installation files for the SDK and for Code Composer Studio (CCS). We have no need for a third partition to use as general storage, so select the 2partition option. 13. (create-sdcard.sh) Enter y to continue after partitioning is complete. 14. (create-sdcard.sh) Choose option 2 to use custom files for the boot partition and root file system. The files for the root partition are actually exactly the same as ship with the SDK; however, a few minor changes have been made to the file system, so you will need to install the custom file system. 15. (create-sdcard.sh) Specify the boot.tar.gz archive to be copied into partition 1. Enter the path for Boot Partition: boot.tar.gz Specify boot.tar.gz as the archive of files to be placed in the boot partition. 16. (create-sdcard.sh) Specify the rootfs.tar.gz archive to be copied into partition 2. Enter the path for Rootfs Partition: rootfs.tar.gz Specify rootfs.tar.gz as the archive of files to be placed in the root file system partition. 17. Eject the multimedia card. ubuntu$ sudo eject /dev/sdb For efficiency, Linux rarely writes directly to a device, but instead writes into a RAM buffer, which is then copied to the device. In some cases, the entire buffer may not be
Introduction to Embedded Linux - Lab 1: Booting Linux 1-5
written until the device is ejected, which could potentially cause corruption if the microSD is pulled from the reader before the device is properly ejected. The create-sdcard.sh script actually ejects the device for you (technically it unmounts the device using the umount command for those advanced students who are aware of the difference between the two operations), but it is good practice to get in the habit of always ejecting before removing the micro-SD card just in case it is needed. 18. Remove the mini-SD card from the SD/MMC card reader and insert it into the mini-SD slot of the AM335x Starter Kit. On the AM335x Starter Kit, the metal leads of the micro-SD card should face away from the printed circuit board.
1-6
or
minicom: cannot open /dev/ttyUSB1: Device or resource busy
wait a few moments and try again. 23. Enter user root at the login prompt (no password.) Note: you may need to press the Enter key in order to see the login prompt. Upon a successful boot of Arago Linux, you will be presented the login prompt on the minicom console (after quite a bit of feedback as Linux boots): am335x login: root 24. Establish the Ethernet-over-USB connection by ejecting the AM335x Media Storage gadget driver. Note: this step will not work. This is the method recommended in the documentation, so these instructions have you attempt it as a first step. From the xterm terminal, type: ubuntu$ sudo eject /media/boot Or press the Eject button from the GUI window that displays the /media/boot folder
1-7
The Eject signal sent to the media storage gadget driver informs the driver to switch from Media Storage to Ethernet-over-USB. 25. Verify Ethernet-over-USB connection Note: since step 24 most likely failed, this will not produce the correct result. Step 26 will demonstrate a work-around solution. In the host Ubuntu machine, type the command: ubuntu$ ifconfig If everything has worked correctly, you will see three connection entries eth0, lo and USB0. If it has not worked correctly you will see two entries (eth0 and lo). You may likewise use the ifconfig command on the AM335x starter kit to test the connections, via the minicom connection that you established in step 22. am335x$ ifconfig Again, if everything has worked correctly, you will see three connection entries, and if not you will see two. 26. (If necessary) Manually establish the Ethernet-over-USB connection. If you do not see a USB0 connection established on either the Ubuntu or AM335x starter kit, you will have to manually establish the connection. This is an advanced procedure, so do not worry about the details at this time. The instructions shown here will be explained in Module 6 when drivers are discussed. You can begin by verifying which Linux kernel modules are currently loaded onto the system: am335x$ lsmod Most likely you will see the g_mass_storage driver, assuming that your USB0 networking connection has not been established. If instead you see the g_ether driver, but do not have a USB0 connection, ask your instructor for help. If you see neither, proceed. Assuming that you do see the g_mass_storage driver, remove the driver using: am335x$ rmmod g_mass_storage Finally, manually load the Ethernet-over-USB driver using: am335x$ modprobe g_ether For future use, these instructions have been placed into the script connect_etherUSB.sh that is located in the home directory on the AM335x starter kit. 27. (If necessary) Repeat step 25 if you had to manually connect using step 26. If you still do not have a live connection, attempt (on Ubuntu host): ubuntu$ sudo ifdown usb0 ubuntu$ sudo ifup usb0 If you still do not see a USB0 connection, ask your instructor for assistance.
1-8
28. Verify the Gigabit Ethernet connection. If you have an Ethernet crossover cable connecting the AM335x to the host computer, the Ethernet connection will appear as eth0, for which the subnet gigether.net has been configured using IP ranges 192.168.1.xxx. From the host Ubuntu machine, type: ubuntu$ nslookup am335x.gigether.net Server: 192.168.1.1 Address: 192.168.1.1#53 Name: am335x.gigether.net Address: 192.168.1.2 ubuntu$ ping am335x.gigether.net 29. Verify the Ethernet-over-USB connection. If you load the Ethernet-over-USB gadget driver, the Ethernet-over-USB connection will appear as USB0, for which the subnet etherUSB.net has been configured using IP ranges 192.168.2.xxx. ubuntu$ nslookup am335x.etherUSB.net Server: 192.168.1.1 Address: 192.168.1.1#53 Name: am335x.etherUSB.net Address: 192.168.2.2 ubuntu$ ping am335x.etherUSB.net 30. View the startup configuration. The startup script methodology used by the Arago distribution is called SysV (system five) and is a common startup methodology across various Linux distributions. Much information is available on the internet for those wishing to learn more about SysV. am335x$ ls /etc/rc5.d
1-9
1 - 10
2-1
Module Topics
Module Topics
Lab 2: Linux Terminal Manipulation ......................................................................................................2-1 Module Topics..........................................................................................................................................2-2 (beginner) Basic Terminal Manipulation.................................................................................................2-3 (beginner) Basic File Manipulation .........................................................................................................2-5 (Advanced) Linux Redirection .................................................................................................................2-7 (Advanced) Linux Scripting .....................................................................................................................2-8
2-2
2-3
11. Explore the behavior of the autofill when there is a filename conflict. ubuntu$ ls m<tab> If you were careful to press <tab> just once, you should now see. ubuntu$ ls myhugelongfilename Because both myhugelongfilename1 and myhugelongfilename2 meet the criterion m* the autofill has completed as much as it can up to the conflict. Another useful feature of the autofill is that if you have a conflict, you can press <tab> twice in rapid succession in order to print a listing of all files that meet the current criteria. ubuntu$ ls myhugelongfilename<tab><tab> This should print myhugelongfilename1 and myhugelongfilename2 in the terminal. Note that after these files are listed, the prompt returns to: ubuntu$ ls myhugelongfilename This allows you to enter the next character and resolve the conflict. Finish by adding either 1 or 2.
2-4
Exit the gedit application by pressing the x in the top right corner of the window. 14. Print the contents of myhugefilename1 from the terminal with cat. You can print the contents of a text file using the cat command in Linux. (This is short for concatenate. If you specify more than one filename to the cat command, they will be concatenated together and then displayed on the terminal.) ubuntu$ cat myhugefilename1 15. Print the contents of myhugefilename1 from the terminal with more. The more command has a number of useful features. If the file you are printing is too large to fit on one terminal screen, cat will simply dump everything so that you have to scroll back to see the whole file. more will pause after each page, and you may use the space bar to advance to the next page. ubuntu$ more myhugefilename1 16. Create a subdirectory named subdir. Refer to step 6 if needed 17. Create a copy of myhugefilename1 named mycopy1, where the file mycopy1 is in the subdir directory. ubuntu$ cp myhugefilename1 subdir/mycopy1 18. Create a second copy using the current directory reference . ubuntu$ cp ./myhugefilename1 ./subdir/mycopy2 The single period . in the above command refers to the current directory. It is not necessary to reference the current directory in most instances because it is implied, but there are cases where the current directory reference is useful to know, so we wanted to introduce it here. 19. Verify the copies by listing the contents of the subdir directory. 20. Change into the subdir directory. 21. Change the name of mycopy1 to mynewfilename. ubuntu$ mv mycopy1 mynewfilename The Linux mv (move) command may also be used to change a filename.
2-5
22. Move mynewfilename from the subdir directory up one level to the lab02 directory. ubuntu$ mv mynewfilename ../mynewfilename Note that the double period (..) in the above command refers to the directory one level up from the current directory. Before you ask, there is no triple period. To move up two directories, you would use ../.. In this case, the same effect could have been achieved with: ubuntu$ mv mynewfilename .. If you move a file to a directory, Linux will automatically retain the original file name. 23. Copy everything from the subdir directory up one level to the lab02 directory. ubuntu$ cp * .. The asterisk (*) acts as a wildcard in Linux just as in DOS and Windows. An asterisk by itself will match everything in the current directory, thus the above command copies everything from the current directory into the parent directory. 24. Remove mynewfilename from the subdir directory ubuntu$ rm mynewfilename 25. Change directories up one level to the lab02 directory 26. Remove the subdir directory and all of its contents (recursive removal) ubuntu$ rm -R subdir
2-6
2-7
38. Create a script that will append mystring to any file in the current directory that contains the key phrase mykey The calling format for this script is: ubuntu$ ./myscript.sh mystring mykey A few notes about Linux scripting: (For more information, refer to Learning the Bash Shell by OReilly Publishing.) a. The first argument passed to the script may be referenced with $1 (without the quotes), the second with $2, etc. b. You can create a for loop from any space-separated list using the following format. The below example script would perform similarly to the ls command: for file in ./* do echo ${file} done c. You can test with an if statement. The following example script will print the name of the variable file only if it matches the string testfile if [ ${file} == testfile ] then echo ${file} fi note that the variable ${file} is in quotes. This is for proper handling of the case in which the variable ${file} is empty. Without the quotes, there would be a syntax error because there is no left-hand side to the test. With the quotes, the test will hold correctly in the case of an empty variable because the left-hand side is an empty string. Note that the space after the initial [ bracket is required, as is the space before the final bracket. d. You can test if a file contains a given string with the grep command. grep is a very useful search utility, which along with sed (a serial editor utility which can do search-and-replace) is very commonly used in Linux scripting. To test if the file myfile contains the string mykey, you could use the test:
if [ `grep c mykey myfile` -ne 0 ]
Passing the -c option will instruct grep to count the occurrences of the following string. By placing the full command in right-facing single quotes, the command is executed in the shell and the result is inserted in place of the expression. Note that both the initial and final quotation marks must be rightfacing. 39. Change the permissions of myscript.sh to add executable permission for all users ubuntu$ chmod a+x myscript.sh
2-8
40. Create one or more test files in the lab02 directory and test your script. Note: The solution is shown on the next page. Correct operation is as shown below:
2-9
41. Solution:
2 - 10
Lab 3: git
Introduction
In this lab exercise you will explore the git tool, an open-source tool for version control. You will create an empty git repository and manipulate test files from the Linux terminal, using the git tool to save commits in between changes and then restore previous commits using tags. You will also create a second branch and use the git merge capability. In the next lab exercise, you will build on this knowledge using the git eclipse plugin to save commits of lab exercises and, if necessary, use the diff utility to compare your project to the solution files, which are committed on a separate solutions branch.
3-1
Module Topics
Module Topics
Lab 3: git .....................................................................................................................................................3-1 Module Topics..........................................................................................................................................3-2 Exploring gits Own git Repository..........................................................................................................3-3 Create a New git Repository ....................................................................................................................3-5
3-2
1. Determine current version of git ubuntu$ git --version The current git version is v1.7.9.5 You will see in a moment that the git repository has a newer version. The reason an older version is currently installed on the machine is because it was installed using the aptitude package manager (apt-get command) Typically the version of git that is downloaded using aptitude will be a version or two behind what is available on the maintainers git repository, so the procedure in this lab exercise is typical for installing the latest version of git: step 1 you use aptitude to install a version (not necessarily most current) of git on the computer, then step 2 you use this version of git to download the latest version using the maintainers git repository. 2. Display the git repository branches ubuntu$ cd /home/user/labs/lab03_git/git ubuntu$ git branch The output of this command shows that there is only one (public) branch for this repository, named master. The asterisk indicates that this is the currently checked-out branch. 3. Search the git repository tags ubuntu$ git tag The output of this command will show you version numbers. The version numbers that end in -rcX indicate release candidates. The versions with three numbers are the actual released versions and the versions with four numbers are intermediate versions. Note that the last released version of this git clone is v1.7.9.7 4. View the commit log between v1.7.9.5 and v1.7.9.7 Not all commits are tagged. If you wish to see the details of every commit that was made between the currently installed version and the latest version use ubuntu$ git log v1.7.9.5...v1.7.9.7 (note: three periods between tags)
3-3
You may scroll through the log with the up and down arrow keys. Press q to quit. 5. Check out (i.e. switch to) the v1.7.9.7 branch of the repository ubuntu$ git checkout v1.7.9.7 You will see a warning message from git indicating that you are in detached HEAD state. This basically means that any changes you make cannot be pushed back to the remote repository. If we wished to make modifications to the code at this commit, we would want to follow the advice given i.e. checkout with the -b option which would create a new branch at the v1.7.9.7 commit point where our changes would be stored. However, since all we want to do is rebuild the code, this isnt necessary. 6. Rebuild and install git ubuntu$ make prefix=/usr all ubuntu$ sudo make prefix=/usr install 7. Check git version ubuntu$ git --version git should now report version1.7.9.7
3-4
3-5
23. Check out the previous commit ubuntu$ git checkout HEAD^ Note: You will get a detached HEAD message. This is expected and will be explained further in step 25. The caret (^) symbol in a git context is used to refer to the commit previous to a given reference. Recalling that HEAD references the users current position within the git tree, HEAD^ would be the last commit. The caret symbol may be stacked, i.e. HEAD^^ and it may also be used in conjunction with other references such as tags. (v1.0.1^) Note that the caret will always reference the previous commit, so that v1.0.1^ will only take you to the v1.0.0 tag if there are no untagged commits inbetween. 24. Print the current testfile 25. Check out the initial commit by its tag (v1.0.0) As in step 23, you will get a message indicating that you are currently in the detached HEAD state. Whenever you check out a tag (or commit) as opposed to checking out a branch, you will be placed into detached head state. Detached head state means that git is maintaining a virtual branch from the commit to store any changes you make. This detached head state is required if you check out a commit that is not at the tip of a branch because there is no way to track changes at a mid-point of the branch without creating a new branch. However, even if you check out the final commit of a branch, you will be placed in detached head state. If you want to append changes to a branch without creating a new branch, you should check out the branch itself, as opposed to checking out the final (or any other commit) in the branch. 26. Print the testfile 27. Create a new branch off of the v1.0.0 tag ubuntu$ git branch test 28. Print a list of branches ubuntu$ git branch You should see: * (no branch) master test The asterisk next to no branch indicates that you are currently in detached head state. 29. Move to the test branch ubuntu$ git checkout test 30. Create a new file named testfile2 with the following text: ubuntu$ echo Mod 1, test branch >> testfile2 31. Commit your change (without tag) Dont forget to git add testfile2 into the index! 32. Modify testfile and use git add to add it for staging 33. Modify testfile2 again, but do not use git add to stage it 34. Create a new file named testfile3, and do not use git add to add it to the index.
3-6
35. View the current status of the git repository ubuntu$ git status you should see: # On branch test # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: testfile # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: testfile2 # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # testfile3 36. Commit your change and tag as v1.1.1 37. Print the log Note that the log shows commits only for the current branch 38. Checkout the master branch You should get an error indicating that your local changes to testfile2 would be overwritten by checking out the master branch. This is because in step 36, only the changes to testfile were added to commit v1.1.1 There are two solutions when this occurs. The first solution would be to create a new commit and git add testfile2 In some cases, however, you might want to (permanently) discard whatever remaining local changes have been made and perform the checkout. This can be done using: ubuntu$ git reset --hard ubuntu$ git checkout master 39. Do a list command (ls) You should see testfile and testfile3 but no testfile2. testfile is present because it is present in this commit node of the git repository. testfile3 is present because, even though it is not present in this commit node of the git repository, it is an untracked file, indicating that it is not effected by the git checkout command. testfile2 is not present because it is not present in this commit node, but it is a file that is tracked by the git repository (i.e. in the git index). 40. Merge the test branch into the master branch ubuntu$ git merge test 41. Do another list command The master branch now has testfile, testfile2, and testfile3. Try printing the contents of testfile2 with the cat command.
3-7
3-8
CCSv5 Installation
Weve installed CCSv5 into the /home/user/ti folder
4-1
Module Topics
Module Topics
Lab 4: Code Composer Studio Debug ......................................................................................................4-1 Module Topics..........................................................................................................................................4-2 Test Secure Shell Protocol .......................................................................................................................4-3 Create Project ..........................................................................................................................................4-5 Setup CCSv5 Remote System Explorer Connection ...............................................................................4-12 Setup CCSv5 Debug Configuration .......................................................................................................4-19
4-2
Name: am335x.gigether.net Address: 192.168.1.2 To verify address resolution on the Ethernet-over-USB connection: ubuntu$ nslookup am335x.etherusb.net Server: Address: 192.168.1.1 192.168.1.1#53
Name: am335x.etherusb.net Address: 192.168.2.2 From here on, the instructions will assume that you are using a gigabit Ethernet connection. To run the lab using the Ethernet-over-USB connection, substitute am335x.etherusb.net in place of am335x.gigether.net 3. Test connection ubuntu$ ping am335x.gigether.net 4. Establish a secure shell (ssh) connection between host and Beaglebone ubuntu$ ssh root@am335x.gigether.net Currently there should be no key on file for the hostname you are connecting to and you should see a message:
4-3
The authenticity of host am335x.gigether.net (192.168.1.2) cant be established This message is shown in the screen capture below:
If you get this message, type yes at the prompt and ssh will generate a new key for you. If you get an error message when attempting to connect ssh, execute the clear_ssh.sh script from the lab00_utils directory: ubuntu$ ~/labs/lab00_utils/clear_ssh.sh This script will clear any key that may currently exist for the AM335x starter kit, allowing the generation of a new key via the procedure shown above. 5. Press Enter key when prompted for password There is no root password on the AM335x starter kit, so when ssh prompts you for a password, simply press Enter. 6. Explore Terminal You can navigate an ssh terminal exactly as you would a minicom or screen terminal as you have been using previously. 7. Exit from ssh am335x$ exit (From within the terminal where you launched ssh)
4-4
Create Project
Create Project
1. Start CCSv5 from the Ubuntu desktop.
2. Select the /home/user/labs/lab04_workspace Workspace By default, CCS will query you for the workspace you would like to use each time it starts as per the following window:
The workspace contains general information that is outside the scope of individual projects such as the debugging connections that have been configured and the general settings for the IDE. Each lab exercise is organized into its own workspace for this workshop. If you choose to select Use this as the default and do not ask again on this screen, you can switch between workspaces after CCS has loaded by using FileSwitch Workspace
4-5
Create Project
Eclipse provides many different types of projects. The project type selected will affect which build tools are used to build your project CCS Project uses Eclipses managed make capability, which builds and maintains the make file for you as you add/subtract items and settings from the GUI. By default, a CCS Project builds with the compiler, assembler and linker that are shipped with Code Composer Studio. C/C++C++ Project (or C Project) uses Eclipses managed make capability, but gives you a wider range of options for specifying the build tools you wish to use (whereas CCS Project will automatically use the build tools that come with CCS.) We will use this project type and specify the arago distribution gnu compiler chain (gcc) build tools. C/C++Makefile Project with Existing Code uses your own makefile; while this leaves the work of building and maintaining your own makefiles, it gives you absolute control over your builds Qt allows you to import a qtopia project, i.e. a project you created using QT Creator and/or QT Designer.
Well create a C/C++ C++ Project as shown in the following diagram. Select in the tree and then press Next.
4-6
Create Project
On the next screen, name the project lab04_project and select Cross-compile Project from the Executable project type.
Note: Be sure to press Next> and not Finish on this screen, or you will not be taken to the next screen to specify the location of the cross-compiler tools. You will need to provide the location and name of the cross-compile toolchain on the system. It is recommended that you use the Browse.. button to select the Tool command path as a single typo will cause problems later. The Tool command prefix is everything in the command that comes before gcc for the cross-gnu compiler chain tools.
4-7
Create Project
You can press Finish at this stage, but if you would like to see the options that are provided on the final screen, press Next> and then select Finish from the final screen.
4-8
Create Project
6. Build your program ProjectBuild All (ctrl-b) 7. (Optional) Debugging Tip If you have build errors indicating that the cross-compile tools were not found, such as:
Right-click on the project folder in the project explorer window and select Properties
4-9
Create Project
Here you can double-check and, if necessary, correct any errors to the cross-compiler tool chain settings. 8. Create a new git repository for your project using Egit (Eclipse git plugin) Right-click on project in the Project Explorer and select: TeamShare ProjectGit
Press the Create button next to the Repository entry and fill in
9. Commit project files Right-click the project in Project Explorer and select: TeamAdd This will add all files (except those in .gitignore) Next right-click the project again and select TeamCommit You can accept the defaults, which will commit the changes with username user and email user@ubuntu Next, enter a useful commit message such as Initial commit of a simple hello world CCSv5 project. And press commit button.
4 - 10
Create Project
10. Create a tag to reference your commit Right-click on the project in Project Explorer and select: TeamAdvancedTag
4 - 11
Enable CDT GDB Debugging and RSE Project, and then click OK.
4 - 12
12. Open the remote systems view Window Show View Other Remote Systems Remote Systems
13. Configure a new connection using the Remote Systems menu or by pressing the new connection button
4 - 13
Remote System Type: Linux Host Name: am335x.gigether.net Connection name: Gigabit Ethernet to AM335x Description: Connection to hostname am335x on the .gigether.net subnet
4 - 14
On third screen (files) select ssh.files under configuration and on the fourth screen (processes), select processes.shell.Linux under configuration.
4 - 15
On the fifth screen (shells) choose ssh.shells and on the sixth screen (ssh Terminals) choose ssh.terminals. You may press Finish on the sixth screen.
4 - 16
15. Change the ssh login user ID to root Right-click Gigabit Ethernet to Beaglebone in the Remote Systems window and select Properties
Change Default User ID to root as shown: Note: You may need to press the small button that appears between Default User ID: and the entry box if the entry box is grayed over.
Press OK
4 - 17
16. Connect to target using newly created connection Right-click on Gigabit Ethernet to AM335x in the Remote Systems window and select Connect You may get a message indicating the ssh service does not recognize the RSA key fingerprint of the AM335x starter kit. This is the same message that you should have seen in step 4 from the terminal, and it will only appear if you did not generate a new key in that step. If it appears, press Yes to continue connecting and you should not see it a second time.
17. Test connection with filesystem viewer If you have successfully connected the RSE, you should be able to expand the SFTP files tab under the connection as shown:
18. (Optional) Configure Ethernet-over-USB connection You can do this by repeating steps 13-17 using the following Remote System Type: Linux Host Name: am335x.etherusb.net Connection name: Ethernet-over-USB to AM335x Description: Connection to hostname am335x on the .etherusb.net subnet
4 - 18
4 - 19
20. Setup the configuration: Use the following settings (many of these should be set by default): Name: Project: C/C++ App: Connection: Remote Path: lab04_project Debug lab04_project Debug/lab04_project Gigabit Ethernet to AM335x /home/root/lab04_project
4 - 20
21. On the Debugger Main tab, specify the GDB debugger. We are using the GDB debugger from the TI SDK, so browse for the correct gdb client executable.
/home/user/ti-sdk-am335x-evm-05.05.00.00/linux-devkit/bin/arm-aragolinux-gnueabi-gdb
You may wish to view /home/user/.gdbinit which had to be added for gdb/CCS to correctly locate shared object libraries. Note that if you browse to this file, it is hidden. You will need to right-click in the file browser and select show hidden files.
The gdb initialization file at /home/user/.gdbinit contains a single line: set sysroot /home/user/ ti-sdk-am335x-evm-05.05.00.00/targetNFS This instruction tells gdb to search for Linux shared libraries in the /home/user/ tisdk-am335x-evm-05.05.00.00/targetNFS directory which is a mirror of the filesystem we are running on the SD card. (This directory was used to burn the SD card in the first lab exercise.) If this step were skipped, the debugger would still work, but a number of warnings would be generated indicating that the debugger cannot locate various shared libraries. 22. Press the Debug Button to begin Debugging your application. Alternately you could press the close button and manually start debugging using Rundebug (F11)
4 - 21
23. After clicking Debug, the IDE will switch into the Debug Perspective. It will then load the program and execute until it reaches main().
4 - 22
24. View remote terminal You can view the ssh terminal in which the application is running from the Display Selected Console dropdown in the console window
Select the Remote Shell terminal and you will see the message Hello World! displayed after you step over the printf statement. 25. Run through the application once You may press the start button 26. Restart the application After each run through of the application, the gdbserver application terminates and a new session must be restarted. This is also what will happen if you press the stop button select RunTerminate (ctrl-F2) or or use RunResume (F8)
You may restart by pressing the bug button You can press the button without using the pull-down menu, or by using the pull-down and selecting ccslab Debug Note that if you wish to halt a running application without ending the debug session, you must use the pause button or RunSuspend
4 - 23
27. Set some breakpoints, single step, view some variables You can set a breakpoint by right-clicking on a line of code and selecting RunToggle Breakpoint, or by pressing (Ctrl-Shift-B). You can also double-click the area just to the left of the code line in the display window. You can step over a line of code with RunStep Over (F6), or by pressing the step-over icon. You can run to the next breakpoint with RunResume (F8) or by pressing the run icon. You can view a variable by right clicking and selecting Add Watch Expression Of course, this is a very simple hello world program but feel free to add a variable or two and restart the debugger. Note that any changes made will not take effect until you halt the current debug session, rebuild the application, and then re-launch a new debug session. In order to make changes, you will need to Press the stop button (ctrl-F2) Edit the main.c file and then press filesave (ctrl-s) Rebuild the program with ProjectBuild all (ctrl-b) Relaunch the debugger with RunDebug (F11) 28. Exit debugging and return to edit Perspective Often during development it is more convenient after a quick debugging test to exit the debugger and return to the code editing perspective. Even though it is possible to edit code, rebuild and rerun in the debugging perspective, the editing perspective is generally more useful for making more significant changes. To switch back to the editing perspective, Press the stop button or select RunTerminate (ctrl-F2) or RunTerminate
4 - 24
5-1
Module Topics
Module Topics
Lab 5: Using GPIO .....................................................................................................................................5-1 Module Topics..........................................................................................................................................5-2 Boot Board and Test GPIO ......................................................................................................................5-3 Part A, Light LED from C Application ....................................................................................................5-4 Part B, Blink LED from C Application ..................................................................................................5-10
5-2
5. Drive the usr0 GPIO to light the LED am335x$ echo 1 > /sys/devices/platform/ledsgpio/leds/am335x:EVM_SK:usr0/brightness If you like, you can turn the LED back off by echoing 0 into the same virtual file.
5-3
From this view, it can be seen that there are three local branches. (This is not a cloned repository, so there are no remote branches.) Currently the HEAD, i.e. the position within the repository is on the master branch. This is shown by the checkmark on the branch icon where master is displayed as well as by the [master] reference at the end of the lab05_git repository listing (the first line). 9. (Optional) Checkout the solution_A branch using the Repositories View Be sure you have main.c open in the editor window by double-clicking in the project explorer window. Now, double-click solution_A in the repositories view. Note that the check mark moves from master to solution_A in the repositories view and the main.c file open in the editor window has been updated and now contains the solution. Note: Be sure to switch back to the master branch when youre done! 10. View the history of your current branch. Right-click on the lab06_project project in the project explorer tab and select TeamShow in History
5-4
This window provides a graphical view of the history (log) of the current branch. This one isnt very exciting because the master branch has only one commit. 11. View the history for all branches Depending on how many branches you have in a given repository, the show all branches button of the history view can be very useful. Lets press this button now, located in the top right of the history window. ( )
5-5
We see from the history window that the solution_A branch is a derivative of the master branch at the first (and only) commit node. The solution_A and solution_B branches have two commit nodes each. The solution_B branch is a derivative of the first solution_A commit. (The initial commit node in each of these branches is the solution for the lab on the Beaglebone, which was updated when the workshop was moved to the AM335x starter kit.) 12. (Optional) View solution A for this lab You can view the solutions using the history window without having to checkout the corresponding branch using git. Simply click on the solution_A marker in the graphical window at top and then double-click main.c in the file listing on the lower right. Note that, as opposed to checking out the branch as in step 10, you have opened a new copy of main.c from the solution_A branch without actually switching to that branch. Because of this, if you had main.c open from the current branch (master) it is unchanged, but a new file, listed as main.c <commit hash> appears in the editor window. 13. Double-check that the master branch is checked out Refer to step 9. 14. In the main.c file of lab05_project, use fopen, fprintf, and fclose to accomplish the equivalent of lab05 steps 3-5 from the previous section, using a C program Here are the function prototypes for fopen, fprintf and fclose: #include <stdio.h> FILE *fopen(const char *restrict filename, const char *restrict mode); int fprintf(FILE *restrict stream, const char *restrict format, ...); int fclose(FILE *stream); Accepted values for the mode field of fopen include: r w rw Read only Write only Read and Write
15. Build your application ProjectBuild All Or (Right-click Project)Build Project 16. Choose Debug Connection Debugging has already been configured for this project in the same manner as you set up in Lab 4. You will only need to choose between the Gigabit Ethernet to am335x and Etherenet-over-USB to am335x connections. Use RunDebug Configurations to bring up the debug configuration Select the lab05_debug configuration, and on the main tab, choose the appropriate connection from the connections pulldown menu. Note that you may have to scroll down in the main window in order to locate the connections pulldown menu.
5-6
17. Test the Application Select lab05 Debug from RunDebug History or use the bug pulldown menu
Upon successful completion, you should see user LED 0 light on the AM335x starter kit. If your code is not working properly, you may want to refer to the next section, A.2: Compare and Commit Your Lab.
5-7
Here we are comparing the starter file to the solution, so the comparison tool indicates that everything in the solution is missing. If you would like to overwrite a portion of your lab with a portion of the solution, you can use these buttons in the top-left corner (hover with the mouse for a description of each)
5-8
5. Commit and tag your changes Refer to lab 04 Debugging with Code Composer Studio for details of committing and tagging your lab. An outline is provided below: (Right-click lab06_project)TeamAdd (Right-click lab06_project)TeamCommit (Right-click lab06_project)TeamAdvancedTag You may use any tag that makes sense to you. Lab_A or master_A are common.
5-9
After writing the toggle value into the virtual file, you will need to use the fflush command; otherwise, the value will be stored in a write buffer but not actually written to the virtual file until the buffer is filled. (fclose automatically performs fflush, so we didnt have to worry about this in the previous lab.) You will also want to use the sleep command to pause for a second between iterations of the loop; otherwise the GPIO will toggle so quickly you will only see a dimly lit user LED 0. The prototypes for these functions follow: #include <stdio.h> int fflush(File *stream); #include <unistd.h> unsigned int sleep(unsigned int seconds); The solution to this exercise (in the solution_B branch of the git repository) also uses signal handling to exit from the while loop when ctrl-c is pressed. When debugging with Code Composer Studio, using signals to end a program is less of a concern since CCS may be used to halt the program when desired. Signal handling will be discussed in the next chapter.
5 - 10
6-1
Module Topics
Module Topics
Lab 6: Serial Driver ...................................................................................................................................6-1 Module Topics..........................................................................................................................................6-2 Boot Board and Test SSH.........................................................................................................................6-3 Remove Serial Console from AM335x Starter Kit....................................................................................6-4 Part A: Simple UART Driver Hello World ..............................................................................................6-6 Part B: Optional Challenge Variables over UART ...............................................................................6-8 Part C: Examination Lab UART Configuration ...................................................................................6-9 Restore Serial Console on AM335x Starter Kit .....................................................................................6-10
6-2
6-3
6-4
13. Reboot the AM335x starter kit You may use the push button on the underside of the main board closest to the power supply barrel connector. If your serial port is still live, you will see feedback from u-boot and the booting kernel, but at the end of the boot process, you should not see a login. You will still be able to login to the AM335x using ssh or a like terminal program, however, once it boots.
6-5
18. You will need to use the driver calls open, write and close to access the UART driver. The device node corresponding to the UART that is exposed over the USB connection is /dev/ttyO0 (this is tty, the capitol letter O, then the number 0)
6-6
Here are a few function prototypes that may help you write your program.
#include <unistd.h> // open returns a file descriptor. // Accepted flags are O_RDONLY, O_WRONLY, O_RDWR int open(const char *pathname, int flags); // count in bytes. Returns number of bytes successfully written size_t write(int fd, const void *buf, size_t count); // close returns 0 on success int close(int fd);
Also, you may wish to use the sizeof C macro, which will return the size of a variable (or array or struct) in bytes. 19. Debug your Hello World program Use runDebug Configurations to select the connection type you would like to use (between Gigabit Ethernet to am335x and Ethernet-over-USB to am335x) and then connect a debug session by selecting lab06_project Debug from the bug menu.
Be sure the serial port terminal (minicom) that you opened in step 1 is still connected to the AM335x starter kit. If the program executes successfully, you should see your message appear on this terminal. Note: If you are unable to get your lab working, dont hesitate to ask your instructor for help. Also, the next section will demonstrate a simple method for comparing your lab exercise to the solution. You may use any tag that makes sense to you. Lab_A or master_A are common.
6-7
Hint: The function snprintf works pretty much exactly like printf, except that it writes to a string instead of writing to the terminal. There is also a function sprintf, but the function snprintf is preferred because it writes at most n bytes to the output string, which guarantees you will not overflow. Here is the function prototype:
int snprintf(char *str, size_t size, const char *format, ...);
An example to write the value of j into the string iteration char iteration[10]; snprintf(iteration, 10, "%d", j); 20. If you would just like to see the solution, you may Replace With the solution, or Compare To the solution: Replace With is quicker, but any differences between your lab and the solution will be lost. Compare To will allow you to import the new portions of code without overwriting what you previously wrote. To replace: (Right-click lab06_project)Replace WithBranch, Tag or Reference And select Solution_B tag. To compare: (Right-click lab06_project)Compare WithBranch, Tag or Reference And select Solution_B tag. 21. Whether you write your own version or use the solution, be sure to commit and tag your lab B before moving to the next section.
6-8
6-9
6 - 10
7-1
Module Topics
Module Topics
Lab 7: Linux Scheduler .............................................................................................................................7-1 Module Topics..........................................................................................................................................7-2 A. B. C. Creating a POSIX thread ................................................................................................................7-3 Real-time Threads ...........................................................................................................................7-9 Using Semaphores .........................................................................................................................7-10
7-2
You have been provided with three starting files. thread.c and thread.h are helper files that you should examine but do not need to modify. main.c is basically empty and will be where you write your application.
7-3
5. Examine thread.c You can double-click the file in the explorer window or (right-click)open This file defines a single function, which is a template for launching a POSIX thread.
int launch_pthread( pthread_t *hThread_byref, int type, int priority, void *(*thread_fxn)(void *env), void *env )
is equivalent to passing the handle by reference (as opposed to pass by copy.) The handle pointed to will be overwritten by the pthread_create function so that it is effectively used as a return value. int type: REALTIME or TIMESLICE as #defined in thread.h int priority: 1-99 for REALTIME thread or 0 for TIMESLICE void *(*thread_fxn)(void *env): this is a pointer to a function, where the function takes a single (void *) argument and returns a (void *) value. This is a pointer to the function that will be the entry point for the newly created thread. In C, a pointer to a function is just the name of the function. The entry point for a POSIX thread must be a function with this prototype. A (void *) pointer is like a skeleton key any pointer type may be passed through a (void *) argument. In order for such a pointer to be referenced within the function, however, it must be type cast. void *env: this is the argument that will be passed to the thread function upon entry into the newly created POSIX thread. 6. Open main.c 7. Examine the thread_fxn template
/* Global thread environments */ typedef struct thread_env { int quit; // Thread will run as long as quit = 0 int id; sem_t *mySemPtr; sem_t *partnerSemPtr; } thread_env; thread_env thread1_env = {0, 1, NULL, NULL}; thread_env thread2_env = {0, 2, NULL, NULL}; /* Thread Function */ void *thread_fxn( void *envByRef ) { thread_env *envPtr = envByRef; }
The thread function takes the standard (void *) argument; however, note that it type casts this pointer as a (thread_env *). The thread environment type is defined just above and contains four elements. By passing a pointer to this structure, you are effectively passing these four elements as parameters to the function.
7-4
8. Write the thread function For this first stage of the lab, you will only use the quit and id fields of the environment structure. Your thread function should have three phases: 1. Print a message to stdout (will be printed to terminal) indicating that the thread has been entered. Be sure to indicate the thread ID (envPtr->id) in this message. 2. Enter a loop that will repeat as long as the quit variable (envPtr->quit) is zero. Inside this while loop, print a message to indicate you are inside the loop, again indicating the thread ID, and then enter a spin loop to pause before the next message (or else your terminal will quickly become flooded with messages!) A good delay value is: for(i=50000000; i > 0; i--); Note: *Do not* use the sleep function. It is important for the lab that this is an actual spin loop, even though that is not good programming! 3. After exiting the while loop, print a final message to indicate that the thread is exiting (include the thread ID in the message) and then return the thread ID as the return value of the function. Note: you do not need to create a return structure. Since both pointers and ints are 32-bit on this architecture, you may cheat and simply recast the ID as a (void *): return (void *)envPtr->id; 9. Write the main function The main function should have the following 5 phases: 1. Print a message indicating you are launching thread 1, then launch this new pthread using the launch_pthread function defined in thread.c. Store the handle to the newly created thread in the thread1 variable, and pass the thread1_env environment structure. Be sure to launch as a TIMESLICE thread. 2. Print a message indicating you are launching thread 2, then launch this new pthread using the launch_pthread function defined in thread.c. Store the handle to the newly created thread in the thread2 variable, and pass the thread2_env environment structure. Be sure to launch as a TIMESLICE thread. 3. Print a message to indicate that the application threads have started, then sleep the main thread for 10 seconds using: sleep(10); 4. Change the quit field of the thread1_env and thread2_env environment structures to 1. 5. Use pthread_join to halt the main thread until both thread1 and thread2 have exited. Be sure to capture the return values of these threads in the thread1Return and thread2Return variables. Print a message indicating which threads have exited using the thread1Return and thread2Return variables (Recall that the return value of the thread_fxn is the thread ID).
7-5
10. Link the pthread library into the project (Right-click lab07_project)Properties C/C++ BuildSettingsCross G++ LinkerLibraries Press the add library button And in the pop-up window, type pthread
11. Build the lab07_pthread_lab project In the project explorer, (right-click lab07_pthread_lab)Build Project or ProjectBuild All (ctrl-B) 12. Debug any build errors Dont forget your two resources for lab writing: (right-click lab07_pthread_lab)Compare WithBranch, Tag or Reference Localsolution_A Or ask your instructor for help. 13. Once the program has built, launch a debug session Use runDebug Configurations to select the connection type you would like to use (Between Gigabit Ethernet to am335x and Ethernet-over-USB to am335x) and then connect a debug session by selecting lab07_project Debug from the bug pulldown menu.
7-6
) or RunResume (F8)
7-7
17. You should see something like the following output (you may have to re-select the Remote Shell view after program terminates) Note: Due to non-determinism of Time-Slice scheduling, results may appear slightly different than as in the window below
7-8
Real-time Threads
B. Real-time Threads
18. Change thread1 to a REALTIME thread with priority 99 19. Change thread2 to a REALTIME thread with priority 98 20. Rebuild, launch the debugger, and view the Remote Shell output You should see an output that matches the following:
21. What difference do you see between this output and the TIMESLICE thread output? Why?
7-9
Using Semaphores
C. Using Semaphores
22. In main.c thread_fxn, change the while loop for the following functionality: 1. Do a semaphore wait operation using the threads my semaphore pointer (envPtr->mySemPtr) 2. Do a sleep(1); after the completion of the semaphore wait operation to slow the system down. (This should replace the for loop that was previously used to delay the system.) 3. Keep the print statement to indicate that execution is inside the while loop of the thread, printing the thread ID 4. Finish the loop by posting the partner semaphore (envPtr->partnerSemPtr) 23. In main, create and initialize the semaphores pointed to by thread1_env->mySemPtr and thread2_env->mySemPtr You will need to use the malloc function to allocate memory for both semaphores, followed by the sem_init function to initialize the semaphores. Be sure to set the initial values for both semaphores to 0. 24. Initialize thread1_env->partnerSemPtr to point to the same semaphore as thread2_env->mySemPtr and vice-versa 25. Create a trigger semaphore post in main to post thread1_env->mySemPtr after both threads have been created The thread_fxn has been set up so that both threads will start upon creation with a semaphore wait operation. Since both semaphores were initialized to 0, something needs to kick off one of the threads or nothing will ever happen. Once thread1 is kicked off with the first semaphore post from main, it will post the semaphore for thread2, and from there out there is a one-to-one correspondence between the semaphore wait operations and the semaphore post operations. An alternative to the triggering post in main would have been to initialize the thread1_env->mySemPtr to an initial value of 1. 26. Rebuild, launch the debugger, and view the Remote Shell output You should see output that matches the following:
7 - 10
8-1
Module Topics
Module Topics
Lab 8: Berkeley Sockets .............................................................................................................................8-1 Module Topics..........................................................................................................................................8-2 A. B. C. D. Network Configuration Files ............ Error! Bookmark not defined.-Error! Bookmark not defined. Berkeley Socket Client .....................................................................................................................8-3 Build and Launch the Host Server ..................................................................................................8-4 Server Application ...........................................................................................................................8-6
8-2
8-3
After a successful completion of the make script, a new executable named enetserver will appear in the directory. 12. Launch the application with root permissions using the sudo command ubuntu$ sudo ./enetserver Until you launch the client application you will not see anything happen. The server program will wait for a connection to be requested by a client, and upon opening a connection will echo any message received to the terminal. If all goes well, you will see the message you wrote into the client appear on this terminal once the client application is run. 13. Change back to the CCS window and launch the lab08_project application using the CCS debugger Be sure to press the resume button after launching the debugger as CCS will halt the application at the start of main after it is loaded. 14. Examine the x86 server application
8-4
15. Exit the x86 server application by pressing (ctrl-c) You must have focus within the terminal window in order for the (ctrl-c) to take effect. If nothing happens when you press (ctrl-c), use the mouse to select the terminal window.
8-5
Server Application
C. Server Application
16. If you have not already done so, exit the server application with (ctrl-c) 17. In one of the x86 host computer terminals, change to the /home/user/labs/lab08_x86_server directory 18. Run a make clean operation to remove the current server binary 19. Change to the git tree master branch In section B you used the solution_A files to test the client application. This git tree also contains a master branch with starting files. To revert to the starting files use ubuntu$ git checkout master (Note: if you use git checkout start instead, you will revert to the same start files; however, you will be in a detached HEAD state, which is less preferable.) 20. Open main.c for editing ubuntu$ gedit main.c 21. Examine provided signal structure The main.c starting file has been set up with all of the header files you should require as well as with a registered signal handler for SIGINT (ctrl-c). The signal handler will clean up the current connection and socket by closing ConnectFD (connection file descriptor) and SocketFD (socket file descriptor.) It is important that these file descriptors are properly closed before exiting the application; otherwise they will remain open and will block any further connection via the specified IP address and port. 22. Within the main function, open a socket with the socket function and bind it to an IP address and port with the bind function family: port: address:
AF_INET 1100 INADDR_ANY (you could also use 192.168.1.1)
23. Ready the socket to accept connections with the listen command 24. Create a while loop to accept connections and read data as it comes across The while loop should have the following stages: 1. Begin the while loop by accepting a connection from the socket. (This function will block until a connection request is made from a client) 2. Create an inner while loop that reads a byte from the connection and writes it to standard out (you can use STDOUT_FILENO as the file descriptor for standard out.) You should exit from the inner loop when the read command returns 0 for the number of bytes read, which indicates a termination of the connection. 3. After exiting the inner while loop, indicating the connection was closed by the client, close the connection on the server side with the close command. The solution also prints a message to standard out to indicate that the connection was closed at this point. 25. Save the file 26. Rebuild the server executable ubuntu$ make 27. Test your server executable with the known-good client that you wrote in section C
8-6
09 - 1
Module Topics
Module Topics
Lab 09: Framebuffer Driver .....................................................................................................................9-1 Module Topics..........................................................................................................................................9-2 Copy-based Framebuffer Application ......................................................................................................9-3 mmap-based Framebuffer Application ....................................................................................................9-4 Double-buffered Framebuffer Application...............................................................................................9-5
09 - 2
09 - 3
The return value is a user-space (i.e. virtual) pointer to the newly mapped memory buffer. Most of the parameters that have been provided for you are unlikely to change. Passing a value other than zero in the initial address field allows you to request a specific physical address for the framebuffer to be mapped to, which is rarely used. The prot field indicates that the mapped memory can be written and read. The MAP_SHARED flag indicates that the changes will be written to the underlying file (i.e. framebuffer) as opposed to MAP_PRIVATE, which would allow reading of the framebuffer, but would write all changes to a private copy of RAM and never update the framebuffer. The offset field specifies the offset within the framebuffer where the mapping into program RAM will begin. 11. Modify the pixel manipulation within your nested for loops to write directly into the memory mapped region. You will no longer require the write driver function. Instead, you can use the memory mapped array to write directly into the framebuffer. 12. Build, test and commit.
09 - 4
09 - 5
19. Implement the FBIO_WAITFORVSYNC workaround. The FBIO_WAITFORVSYNC ioctl has not been integrated into the mainstream Linux fbdev driver, so you will have to use the following definition at the top of main.c (after the header file include statements): #define FBIO_WAITFORVSYNC _IOW('F', 0x20, u_int32_t) Note: be sure not to put a semicolon at the end of this line. 20. Build and run the application. As described above, the application draws exactly the same pixels into the ping and pong buffers, so it may not be obvious that anything has changed. This is a good point to test the code, however, and determine if everything is working properly up to this point. 21. (Optional) Implement some form of motion. If you have extra time, you may want to implement some form of motion in the display, such as horizontal scrolling between iterations of the loop. Motion will demonstrate the necessity of a double-buffered system as a properly implemented double-buffered system will not have tearing artifacts as would appear in a single-buffered system attempting motion.
09 - 6
10 - 1
Module Topics
Module Topics
Lab 10: Using QT Creator .......................................................................................................................10-1 Module Topics........................................................................................................................................10-2 x86 Hello World .....................................................................................................................................10-3 AM335x Hello World .............................................................................................................................10-7 Remote Debugging with QT Creator ...................................................................................................10-10
10 - 2
2. Create an empty QT project. FileNew File or Project (ctrl-n) Select Other Project from the Projects menu and Empty Qt project from the submenu, then press the Choose button.
10 - 3
On the Target Setup screen, select Desktop checkbox and deselect the other two. Expand the Details for the Desktop configuration and configure as shown:
When finished, press the Next> button. On the Project Management screen, select git in the Add to version control: field and press Finish to add the new project. 3. Add a simple Hello World main.cpp file. FileNew File or Project Select C++ under Files and Classes section and select C++ source File in the subsection, then press the Choose button.
In the next window, name the file main.cpp and place in the /home/user/labs/lab10a_qtcreator directory (which should be the default.)
10 - 4
Press Next> and select the following file properties (should be the default.)
Press Finish. 4. Enter a short program into main.cpp Enter the following program:
Save with FileSave main.cpp 5. Commit the project. ToolsGitCommit Select the check all checkbox to select all project files to be committed. Enter a suitable description, such as Initial Hello World commit and press the Commit file(s) button and then press Yes in the pop-up window to accept the commit.
10 - 5
6. View the status of the git repository. ToolsGitBranches There should be a single branch named master. 7. View the commit details. ToolsGitLaunch gitk 8. Configure the Project Build settings for x86. Select Projects from the left-hand pane. Default build settings will build a QT application for the x86 platform. This is a good way to test the application on the local system before deploying it to the AM335x Starter Kit. One benefit of the Qtopia environment is portability. Most Qtopia applications can be developed and debugged almost entirely within the x86 environment before being deployed to the target board. The build settings should appear as follows:
Note: The build directory will probably appear in red. This indicates that the specified directory doesnt exist. This is fine; QT Creator will create the directory on the first build. 9. Build the project for the x86 platform. BuildBuild Project Lab10_qtcreator 10. Test the project. BuildRun A 320x240 pixel Hello World window should appear in the top-left corner of the screen. You may resize or close the window as you would any other window in the Gnome desktop environment.
10 - 6
11. Configure Project Build settings for the AM335x. Select Project from the left-hand pane. Under Build Settings by the Edit build configuration: label, and select Cortex A8 (QtEmbedded-4.7.2) Release. Under the General section, by the Tool chain: label, select GCC (Cortex A8). Your final build settings should appear as follows:
12. Build the project for the AM335x. BuildBuild Project lab10_qtcreator 13. Add Installs field to lab10_qtcreator.pro Open lab10_qtcreator.pro by double-clicking the file in the project outline. Add the two declarations shown below and save:
10 - 7
14. Configure a connection for the AM335x starter kit. Select the Projects tab from the left-hand pane and then select Run from the Desktop selector at the top of the page. In the Deployment section, pull down the Add menu and select Deploy to Remote Linux Host. In the new section that is presented after selecting Deploy to Remote Linux Host, rightclick Manage device configurations. This will bring up the Options window at the Linux Devices tab. Click the Add button and select Generic Linux Device from the pop-up window, then press Start Wizard... and fill in as shown:
15. Configure the Application Deployment for AM335x. Locate the Deployment section from the Run Settings menu of the Projects tab:
10 - 8
From the Add pull-down menu, select Deploy to Remote Linux Host. The new deployment should have (correct) default settings as follows:
16. Configure the application Run settings for the AM335x starter kit. Scroll to the Run section of the project page, just below the Deployment section that you configured in steps 14-16. Select lab10_qtcreator (on Remote Generic Linux Host) from the Add pull-down menu. Add -qws to the arguments field, and the other fields should default to the following (correct) configuration:
17. Test the project. BuildRun A 320x240 pixel Hello World window should appear in the top-left corner of the screen.
10 - 9
Location of Debugging Information: /home/user/labs/ lab10_qtcreator-build-desktop-Cortex_A8__QtEmbedded-4_7_2__Debug/lab10_qtcreator Override Host GDB Start Script: /home/user/.gdbinit
You may also use DebugStart DebuggingStart Debugging (F5) Note: in some cases you will get an error that the file upload failed because the executable file was not found. Usually you will find that the file in question actually does exist exactly where Qtcreator is looking for it! If this occurs, you need to delete the executable on the target (AM335x starter kit) and try again.
10 - 10
Note: If you do not set a breakpoint as shown above, the application will run through to a loop in the return app.exec(); function call and the local variables listing in the top right corner will be empty. As configured, the QT Creator debugger does not implement an automatic stop on entry into main.
10 - 11
10 - 12
Introduction to Embedded Linux - Lab 11: Optimizing Linux Kernel Boot Time
11 - 1
Module Topics
Module Topics
Lab 11: Optimizing Linux Kernel and Filesys .......................................................................................11-1 Module Topics........................................................................................................................................11-2 Benchmark Non-modified Startup Time .................................................................................................11-3 Reduce Filesystem ..................................................................................................................................11-4 Rebuild Linux Kernel .............................................................................................................................11-5
11 - 2
Introduction to Embedded Linux - Lab 11: Optimizing Linux Kernel Boot Time
Introduction to Embedded Linux - Lab 11: Optimizing Linux Kernel Boot Time
11 - 3
11 - 4
Introduction to Embedded Linux - Lab 11: Optimizing Linux Kernel Boot Time
Introduction to Embedded Linux - Lab 11: Optimizing Linux Kernel Boot Time
11 - 5
10. (optional) Rebuild the kernel using the provided build.sh script. Rebuilding the kernel takes seven or eight minutes to complete, so the resulting uImage file has been provided for you in the solution directory of this lab. It is your choice whether you would like to rebuild the kernel and wait it out or just use the solution. 11. Remove the micro-SD card from the AM335x starter kit and attach to the host computer using the MMC/SD card reader. The two partitions of the micro-SD card should automatically mount into Linux (may take 20 seconds or so.) Usually they will mount into /media/boot and /media/rootfs. If the partitions do not automatically mount into Linux, try unplugging the MMC/SD card reader once or twice, and if that does not solve the problem, ask your instructor for help. 12. Copy the stripped uImage Linux kernel to partition 1 of the MMC card. If you rebuilt the kernel, use: ubuntu$ cp arch/arm/boot/uImage /media/boot If you are using the solution, use: ubuntu$ cp ../solution/uImage /media/boot 13. Eject the micro-SD card ubuntu$ sudo eject /media/boot Because Linux buffers write operations to devices such as the MMC/SD card reader, it is important to use the eject command to flush these or any other operations before physically removing the card. 14. Change into the top level of the lab directory. ubuntu$ cd ~/labs/lab11b_kernel_rebuild This will ensure that the capture.out benchmark file is placed at the top level of the lab directory instead of inside the kernel source code. 14. Benchmark the new startup time. Refer to steps 1-4 for help. Your benchmarks should now show approximately 25 seconds to boot. You may compare your results to the capture.out in the solutions directory.
11 - 6
Introduction to Embedded Linux - Lab 11: Optimizing Linux Kernel Boot Time
12 - 1
Module Topics
Module Topics
Lab 12: u-boot Rebuild ............................................................................................................................12-1 Module Topics........................................................................................................................................12-2 Changing Boot Options..........................................................................................................................12-3 Boot Using an Initial Ram Disk (initrd) .................................................................................................12-5 Rebuild u-boot........................................................................................................................................12-6
12 - 2
12 - 3
Note that since the serial console has been disabled, you will see no feedback between Uncompressing Linux done, booting the kernel around 5 seconds and the login prompt, 20 seconds later, so do not worry if the boot process appears to have hung. You may press ctrl-c once the boot process completes in order to exit from the grabserial application in the capture.sh script. You should see a total boot time of about 24.7 seconds. This is only a 0.6 second improvement from the previous lab, but even half a second can be important for some applications.
12 - 4
12 - 5
Rebuild u-boot
Rebuild u-boot
Every facet of the Linux system has been optimized at this point with the exception of the u-boot binary. In this final section, you will rebuild a reduced version of the u-boot binary and recoup the final few seconds of boot time in the system. 8. Change into the /home/user/labs/lab12c_uboot_rebuild/lab12c_git directory. 9. Create a new u-boot configuration file based on the am335x_evm configuration file. The configuration files at <u-boot>/include/configs are used to generate the make config options. By creating a new configuration header file, and then registering via the boards.cfg file (step 10) , a new configuration option will be generated. ubuntu$ cp include/configs/am335x_evm.h include/configs/am335x_fastboot.h 10. Register the am335x_fastboot configuration option in boards.cfg ubuntu$ gedit boards.cfg Copy the entry for am335x_evm and modify the columns as follows: target: arch: CPU: board: vendor: SoC: options: am335x_evm arm armv7 am335x ti ti81xx (empty) am335x_fastboot (no change) (no change) my_am335x_board (no change) (no change) (no change)
11. Create the my_am335x_board board configuration. ubuntu$ cp -R board/ti/am335x board/ti/my_am335x_board Note that the board files are located at: <u-boot>/board/<vendor>/<board> 12. View architecture, CPU and SoC files. ubuntu$ ls arch/arm/lib ubuntu$ ls arch/arm/CPU/armv7/ ubuntu$ ls arch/arm/CPU/armv7/ti81xx/ These source files are pulled into u-boot based on the arch, cpu, and soc fields as specified in boards.cfg. Generally speaking, you should not need to modify them, but if you do, you may create new arch, cpu, and/or soc configurations by copying the relevant folders into new folders in a similar fashion to the new board configuration in step 11. Generally this will not be necessary since the implementation of arch, cpu, and soc is device-dependent and Texas Instruments will provide appropriate configuration for any TI device. In fact, the soc used, TI81xx, is a previous-generation device. This previous-generation device is so similar to the AM335x, that the soc files were simply reused.
12 - 6
Rebuild u-boot
13. View additional imported files. ubuntu$ ls arch/arm/CPU/armv7/omap-common These files are not brought in via the common u-boot arch/cpu/soc structure but have been hard-coded into the Makefile via: ifeq ($(SOC),ti81xx) LIBS += $(CPUDIR)/omap-common/libomap-common.o 14. Generate the .boards.depend file. This step is not required for building, since it will automatically be executed by the Makefile whenever a make configuration step is run; however, it is useful to see the progression of the board configuration through the makefile process. ubuntu$ make distclean Ubuntu$ make .boards.depend The generated file is a hidden file (because the filename begins with a period, it will not be shown by default.) Makefile parses the boards.cfg file and generates this file from it. You may verify that a new am335x_fastboot entry has been added using: ubuntu$ grep am335x_fastboot .boards.depend This should produce output as follows: am335x_fastboot: am335x_fastboot_config; $(MAKE) 15. View the supplied shell script for rebuilding the am335x_fastboot configuration. The steps for rebuilding u-boot can be tedious. A shell script is helpful. ubuntu$ gedit build.sh
export ARCH=arm export CROSS_COMPILE=arm-arago-linux-gnueabiexport PATH=/home/user/ti-sdk-am335x-evm-05.05.00.00/linux-devkit/bin/:$PATH make distclean make am335x_fastboot_config make u-boot.img
16. Execute the build script. ubuntu$ ./build.sh 17. Copy u-boot.img and MLO to partition 1 of the micro-SD card. Be sure to copy both the MLO and the u-boot.img Also, be sure to copy u-boot.img and not one of the other flavors of u-boot that are generated. 18. Eject the micro-SD card. 19. Benchmark the final boot time. You should get a result of approximately 2.6 seconds. This is about the quickest possible to boot from a micro-SD card, but booting from NAND, boot times of less than 1 second have been achieved for similar systems.
12 - 7
Rebuild u-boot
12 - 8