My reflections on SBR600

Hello guys, I will be reviewing my thoughts about this course. I have learned quite a lot in SBR600 and all about Open Source more than I thought I knew.

Some of the things I have learned:

GIT
Basic Python
Compiling from Source
Calculating the j value
Creating Packages
Making a Kernel, modules

The main thing that I had to learn in order to finish my course project was learning as much as I can about ARM devices and cross-compiling for them. Making the kernel and modules to work with an ARM device is a trial-and-error if one does not know what drivers are needed when choosing the options available in the config file.

Below is the Project wiki:
http://zenit.senecac.on.ca/wiki/index.php/Device_Support_and_Testing

Overall, I have learned useful things here that will help me as I move forward. It was a good choice taking this course.

Beagleboard – 0.3 Release

After compiling the kernel and its modules in previous release, I have finalized by packaging the necessary files.

They are available at:

http://scotland.proximity.on.ca/arm/kernel/beagleboard/linux-2.6.36.1/

There was a problem when I first tried compiling the kernel for beagleboard. I got the kernel source from kernel.org but it did not contain the beagleboard_config file which I needed.

So what I had to do was use yumdownloader on my Fedora 13 machine and get the kernel source and browse to the config folder that contains all the config files. I backed up the beagleboard_config file and transferred to the kernel source folder that I got from kernel.org. After that, I was able to compile as mentioned in my previous post.

Beagleboard – 0.2 Release

I have used a different approach in order for making video drivers working for Beagleboard. I compiled a kernel with the video functions that were available from the config file. I also compiled the corresponding video modules that relates to DVI.

This is a guide that I made on how to build a kernel and modules for ARM devices.
http://fedoraproject.org/wiki/Architectures/ARM/Building_a_Kernel_for_ARM

After making the uImage and modules, you can transfer them to appropriate directory of the SD card.

Now for the serial part, use any serial connection program like picocom, or minicom and go into the device.

To restore to the default settings on uboot menu, use:

nand erase 260000 20000

Now use the following commands to setup the boot environment parameters.
mmc init

fatload mmc 0 0×80300000 uImage

setenv bootargs console=ttyS2,115200n8 noinitrd root=/dev/mmcblk0p2 rootfstype=ext2 eq rootdelay=1 nohz=off

saveenv – to save the environment parameters

bootm 0×80300000 – to boot from the specified memory

You will end up on a prompt after the boot.

GIT (Version Control System) Experience

After learning the basics of GIT, I was playing around with the commands.
I ran into some problems because of a silly mistake.

First, I tried cloning the repository using git clone git://(server and its directory)

After changing to the directory that contains the repository, I added a branch for my stuff using git checkout -b Jawwad command.

To push the branch to the server, I used git push –all command and verified that my branch is on the server with git ls-remote command.

From this point, I noticed that I was on the root account of the machine so I changed it to my normal user account and I started having problems because of obvious reason. I noticed that I could not pull someone else’s branch using git pull origin (someonebranch) command.

I had to change the ownership of the branch to myself using the chown command which fixed the issue. I was then able to get someone’s else branch successfully. I checked out the branch using git checkout (someonebranch) command.

A side note: to add/modify contents of the file, use git add (filename) and then git commit to process the changes.

It was a good experience learning things on the development side as this may be useful for me when I get into developing software.

Beagleboard: 2nd phase

After working with BeagleBoard, I tried accessing the serial connection. The trick to make this work is that once the BeagleBoard is powered on, you have to immediately use the command picocom -b 115200 /dev/ttyUSB0 through the terminal if you are on Linux machine in order to connect through the serial connection and press any key when you see a countdown. If you do not press a key, you would have to restart the beagleboard. Once the countdown is finished, it is not possible to get into the serial connection prompt where you can change, add, and delete memory information stored in the BeagleBoard.

Picocom is another tool like Minicom for serial connection. One has to make sure to plug in the serial cable before booting the BeagleBoard. In my case, I was using the serial to USB converter so I ended up using ttyUSB0.

Once you are in the terminal, you can use the help command to see the possible commands that are usable.

At the u-boot prompt, you can use the command nand erase 260000 20000 to erase the settings in the NAND and restore them to their defaults.

In the previous post, I have mentioned that I was able to SSH into the Beagleboard Fedora. I used SSH in order to copy a file called: OMAP35x_Graphics_SDK_setuplinux_3_00_00_06.bin
which is needed to make the drivers working. However, I faced a problem while I was using BitBake which was supposed to fire off a build of the .ipk files.

What supposed to happened was that I would end up with the following files:

libgles-omap3_3.00.00.06-r5.1_armv7a.ipk
libgles-omap3-dbg_3.00.00.06-r5.1_armv7a.ipk
libgles-omap3-dev_3.00.00.06-r5.1_armv7a.ipk
libgles-omap3-tests_3.00.00.06-r5.1_armv7a.ipk

I tried finding an alternate solution and ended up finding this page:
http://www.angstrom-distribution.org/repo/?pkgname=libgles-omap3

This link has the ipk files but I can’t seem to find the dbg file in here which left me hanging.

After one gets these files, they should be copied into /home/root.

Now back to serial terminal, I would have to change the environment variable using

setenv mmcargs ‘setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait omapfb.video_mode=1024x768MR-16@60′ to give the resolution of 1024×768 of the video on the BeagleBoard. It would use these settings on the boot.

Use the saveenv command to save the environmental variables and printenv to make sure that the proper changes are still there.

After restarting the BeagleBoard, it should be booting with 1024×768 60Hz resolution, with 16bpp.

The links that I used as reference were:

http://code.google.com/p/beagleboard/wiki/HowtoUseSGXunderAngstrom

http://processors.wiki.ti.com/index.php/GSG:_OMAP35x_Graphics_SDK_Additional_Procedures

Beagleboard: 1st phase

I am using a BeagleBoard which is running Fedora 12. My goal is to make video drivers run on it so that it can use the built-in DVI video connection which takes in the form of HDMI. It does not support sound, however.

The first thing I did was to connect the mini usb cable on beagleboard and connect it to a linux PC. I then changed the IP of usb0 (that is the name of the network that is viewed by ifconfig) using ifconfig usb0 10.0.0.5 because it has to be in the same network as 10.0.0.1 which is the beagleboard IP.

I was then able to ssh into it and now I am continuing the work.

Stay tuned for more information.

Rebuilding an Existing Fedora SRPM

My choice of rebuilding an existing Fedora package was Apache (httpd).

The steps I followed:-

1. Install the packages: rpm-build, rpmdevtools, rpmlint, yum-utils

2. Execute the command ‘rpmdev-setuptree’

3. You get a hidden file inside your home directory called “.rpmmacros” that you can edit. Changing the “j” value affects the cpu and the speed of compiling the source. I have tried using different values and I will post the results later in the blog.

4. Now change to the ~/rpmbuild/SRPMS/ directory and download the source for “httpd” using ‘yumdownloader –source httpd’

5. Use the ‘yum-builddep httpd*src.rpm’ to install the files needed to build the source rpm of apache.

6. Now install the source using ‘rpm -ivh httpd*.src.rpm’

7. Changing the spec file is possible by editing ~/rpmbuild/SPECS/httpd.spec

8. Finally, change to “~/rpmbuild/SPECS/” directory and execute the command ‘rpmbuild -ba httpd.spec’
***Note: I used the time command to record the time it took to do the specific build. Eg. ‘time rpmbuild -ba httpd.spec’

This was done on a virtual machine, so if I had fedora on a real machine, it would be faster.

Here are the results:

j1
real 4m11.808s
user 2m8.223s
sys 1m33.493s

j2
real 4m6.340s
user 2m12.182s
sys 1m30.366s

j3
real 4m46.809s
user 2m14.831s
sys 2m4.206s

I didn’t think it would build fast as I expected but playing with the “j” value showed the best time. The “j” value of 2 was the fastest as seen above. I have not made this process automated; I built it manually each time changing the “j” value along the way. It seems that the speed depends on how many CPU Fedora is using. I have only assigned 1 CPU to be used by Fedora inside a virtual machine.