Skip navigation

Category Archives: SBR600

I had come into the course not knowing what to expect, the whole community aspect I knew about but was always on the sidelines watching in. I had built small programs before nothing really notes worthy but I had wondered how some of the programs got placed into linux distributions. I learnt how much work has to go into getting a package readily for a fedora distribution and the steps that need to take place for it to be approved.

The major project was where I found I got to really get my hands dirty in the community aspect. My approach was very hap hazard from release to release with no real idea of what my next step would be moving from 0.1 to 0.2 and 0.2 to 0.3. With the guidance of Chris Tyler I was able to get a grip of ideas that would be use full for my project and I mowed ahead. I was able to successfully complete my 0.1 and 0.2 which were getting the PandaBoards in the build farm to see and use more than the 512 MB which is only half the RAM. My 0.2 was to remove the reservation of RAM to VRAM.  Once those two releases where done the PandaBoard where now able to use over 900 MB when they where originally seeing 460 MB. Due to machine failure I was not able to complete my 0.3 which was build factor optimization for the PandaBoard on koji.

This course has given me a reason to reach out into the community and give something back my built MLO and u-boot.bin and part of my video driver less uImage are being used on the PandaBoard build farm for arm.koji. I can say that I have enjoyed this course much more than I thought I would have and looking back I am sure I have gained some skills and knowledge that I will use somewhere down the line either continuing in the community or at work.


For my 0.3 I was to figure out the best build factor on koji for the PandaBoards. Due to unforeseen technical issues with hongkong the arm koji server. Even if the site was fully restored and functionally by Wednesday I am not sure I would have had a moment where I could take down all but one of the PandaBoard builders to do my testing.

So I am going to include some info that was shared with me by our professor Chris Tyler. He had said in his preliminary testing with the httpd package with the build factor set to 4 allowing for two consecutive jobs then running 4 there was a overall increase of jobs done as compared to building 3 jobs in sequence. He had also told me that the httpd package was not really as good test for measuring purposing but for the use of quick testing it was sufficient.

For my 0.3 I will be doing testing on the Koji farm to determine the optimum build factor for the PandaBoards. Currently it is 2 which is the default for Koji, this currently only allows for one task to be built at a time on board which was good for the guru plug and the beagle board, but not the PandaBoard which has more than twice the potential of the other boards on the build farm.

The idea from Chris Tyler is to take down all but one machine on  the build farm and queue a bunch of jobs edit the build factor and watch the time taken for builds and determine what the best build factor is.  The package I plan to test this out on is the firefox rpm for arm. I am planning to do testing on this sometime over the next couple of days.

When the PandaBoard boots it reserves 33554432 bytes (32MB) of RAM for VRAM. As these is no need for video this RAM can be better used by the builder so I went about removing the video drivers from the kernel.

I have successfully compiled a kernel that has no video drivers in it for the purpose of build machines. Thus I was able to reach over 900MB of RAM in the operating system along with the my previously built MLO and u-boot.bin files. How I disabled the drivers from the kernel is that I ran the command

make ARCH=arm CROSS_COMPILE=/path/to/cross/compiler menuconfig

In the menu I went to system type and under ARM System Type I selected TI OMAP. Under that option I went to TI OMAP2/3/4 Specific Features disabled TI OMAP2 and TI OMAP3 and then disabled OMAP 4430 SDP board from the list of the two remaining boards(Figure 1). I then went back to the main menu and went into the Deveice Driver subsection of the main menu. Went down to the Multimedia Support and deselected it. Then went into the graphics support sub menu, disabled all options except Backlight & LCD device support.(Figure 2)

Figure 1 Showing TI OMAP2/3/4/ Specific Features

Figure 2 Showing Graphics Support configuration.

I then exited the menuconfig and saved the config as the default. I then compiled the uImage for the kernel from the .config that got created from the menuconfig with the make command below.

make ARCH=arm CROSS_COMPILE=/path/to/cross/compiler uImage

A copy of the full boot files can be downloaded from here.
The .config that got generated can be downloaded from here

The output from the free -m command that should 907MB available to Fedora is below.

[root@cdot-panda-5-1 kernel]# free -m
Unknown HZ value! (94) Assume 100.
             total       used       free     shared    buffers     cached
Mem:           907         15        892          0          0          3
-/+ buffers/cache:         11        895
Swap:            0          0          0

To avoid errors on boot about not finding modules I copied the /lib/modules/2.6.35-g6d019da-dirty to /lib/modules/

To test the stablilty of my uImage with the 900MB of RAM I did a native compile of the kernel on the PandaBoard. I successfully got the compile without the board crashing that process took about 74 minutes. I am not sure if that is normal for native compiles but I am happy that my board did not seem to have stability issues

This is a update to the 1GB limit. Using armin76’s source guideline , available here, I was successfully able to build a MLO, u-boot.bin that is able to see the full 1GB of the PandaBoard. I had problems getting it to work at first because I had so much variations and failed attempts at these files floating around my machine so I would get confused with which file to use. So after cleaning up after myself I rebuilt the x-loader and u-boot.  When I built the boot.scr file I used the boot parameters from the omappedia release notes for l24.9 Release with the modification of the mem args from PandaBoard FAQ . When trying to boot to was getting a error “mmcinit is not a valid command”. So it turns out that the parameters on the wiki do not work in the boot.scr file. After using the command below to rebuild the boot.scr file with the contents from arm76’s  from source link it now boots.

mkimage -A arm -T script -C none -n "Pandaboard boot script" \
 -d boot.script boot.scr

The memory available to the board after this was originally 421MB with the initial boot.scr of mem=460 and mem=256, the amount of memory available in Fedora was 672MB. The modified boot.scr file with the arguments for both mem to be 460 I was able to get Fedora too see 874MB

I then tested by modifying the second mem parameter to 512 not 256 the board would start but not complete to boot I can only assume the error sig falut because i dont have kernel debug on. Tried to boot a couple more times and it failed at the same point again. So I then edited the boot.scr file and changed the second mem parameter to 460M recreated the boot.scr file I was able to boot the PandaBoard with out any problems, and fedora was able to see 874MB of ram.

I didnt do any heavy load work on the PandaBoard with these settings so I am not sure if there is any instability on the board with this configuration.  The boot folder with all the files that give the OS 874 MB is available for download here.

Output of free -m with  original MLO and u-boot.bin
[root@cdot-panda-5-1 ~]# free -m
 total       used       free     shared    buffers     cached
Mem:           421         43        377          0          2         26
-/+ buffers/cache:         14        407
Swap:            0          0          0

Output of free -m with  mem=460M@0x80000000 mem=256M@0xA0000000
set in the boot.scr
[root@cdot-panda-5-1 ~]# free -m
Unknown HZ value! (87) Assume 100.
 total       used       free     shared    buffers     cached
Mem:           672         45        627          0          2         26
-/+ buffers/cache:         15        656
Swap:            0          0          0

Output of free -m with  mem=460M@0x80000000 mem=460M@0xA0000000
set in the boot.scr
[root@cdot-panda-5-1 ~]# free -m
total       used       free     shared    buffers     cached
Mem:           874         45        828          0          2         27
-/+ buffers/cache:         16        858
Swap:            0          0          0
Total:         874         45        828

My next task is to remove video from the uImage so that specifically the approximately 300 MB of ram doesn’t get reserved for vram, which could potentially allow for fedora to access more of the ram for the build process.

Thanks to armin76 from the pandaboard channel I was able to learn that the reason the board did not see the full 1 GB was because the boot loader that ships with the board and in minimalfs is old and doesn’t support it. Armin76 also gave me good advice on options that I could try with, one of them was building my own from source, or use the one that comes with ubuntu. He also pointed me to websites that provided the materials to accomplish these tasks. The source guideline and the Ubuntu guide line.

I am going to be trying the ubuntu version first and then move onto building my own. I am going to be doing this sometime this week I will post if it is successful or not as soon as I am done.

My configuration is a 64bit version of Fedora 13 running as a virtual machine on a Windows 7 64bit host.

Over the weekend I had the joy of setting up a Panda Board for the first time. I got it working for the most parts with a few quirks. I was following the wiki form omappedia on how to set up validationfs on the PandaBoard. After downloading the filesystem I extracted it to ” “/home/s/pandaFS” and got a boot folder and another tar.gz file, thinking that was weird I extracted the second tar.gz to the same folder (first mistake, will explain why later).  Continuing to follow the instructions I copy the contents of the /home/s/pandaFS/boot folder to the mounted partition of the SD Card. After reading the the file system part I went oo I didn’t need to extract the extract the second tar.gz to this location I could have left it and extracted it to the second partition, silly me.

I now have my validationfs setup and ready to go, or so I think, I connect everything to my PandaBoard and I am ready to go. I run “sudo minicom -s” and configure it to listen to /dev/ttyUSB0 where dmesg tells me my usb to serial dongle is, I save this as the default and off I go. My progress stops short when I encounter the error “Cannot open /dev/ttyUSB0: Invalid argument”  I was like strange maybe this new dongle doesn’t work, so I try again with a dingle that I know works I get the same error message. I switch to Windows and try the dongles using putty and teraterm but I dont get any input from the line.

My next train of thought is that something must be wrong with the way i built the SD card. So I go about redoing the process and decide extract the validationfs to a different directory I then compared the contents of the boot folder of the new extraction to the old and notice they where different. Bringing me back to my first mistake, when i extracted the filesystem tar.gz into the same folder initialy it over wrote some of the contents of the first some so when I copied it over it failed miserably when trying to boot. So I fixed that issue and tried to boot again, staying in windows using putty initially when booting I was now getting information on the serial line but it was not readable, tried teraterm next to see if it was a encoding issue that would be fixed by a different program, no it was not so back to minicom on my Fedora virtual machine I went.

Now that I had confirmed that both dongles work I started minicom and to my dismay I got the same error “Cannot open /dev/ttyUSB0: Invalid argument”, I connected the second dongle and tested to only now get the error Cannot open “/dev/ttyUSB1: Invalid argument” after many hours of google and testing configurations and testing on other virtual machines i still get the same error. When I was close to giving up after a reboot of my host. I then connected the 2 dongles to the vm at the same time tried ttyUSB0 it failed, tried ttyUSB1 and  to my surprise it worked. I was now able to see the prompt for the panda board I was so happy. So now i shutdown the PandaBoard and connect all the peripherals and turn on the board and it successfully completes all tests.

Figuring everything is good I load the minimalfs onto the the second partition of the SD card. I works I see the command prompt on  y serial connection it works I am happy to then find out I am not getting a image on my monitor (Samsung SyncMaster T220HD).  It isn’t to say that it doesn’t detect it because I don’t get the no cable signal error on the screen. I run the monitor tests that the validaitonfs used and it displays the test correctly but not the prompt. After some more time with my best friend google and testing some other settings I cant get it work but since my project doesnt require a GUI I was satisfied that i didnt get it up.

A couple of days later I decided to test the usb dongle when the machine was running Fedora as the host. I boot up into a live CD and attach the dongle, install minicom, configure it to use the usb dongle  and it worked just like that. So for now I am going to use a retired laptop for my PandaBoard testing hoping that it can survive with out overheating.


I configured a default profile for mock because I would be testing my builds on a dist-f13 setup. This was done by creating a symbolic link to the fedora 13 x86_64 config file and naming it  default. When running mock initially it took a while to setup the environment because yum needed to download the packages. Once mock was run once it saves the rpm packages needed to build the mock environment to help with build times as well as bandwidth. My macchanger and wget rpm’s had all the proper build requirements so my mock test were both successful.

I then created my koji account I ran into a small issue where when I initially after I did the set up, when I tried to upload to koji I got a error saying I needed a client certificate. When I initially ran the “fedora-packager-setup” it was as root not my account, so I reran the “fedora-packager-setup” as my user account to fix the issue.
I had no issues building on koji for fedora 14. I then tested my packages on arm and sparc with my packages building successfully on the first go again.


I built RPM’s for the this course where macchanger and wget. The RPM’s are for 64bit machines and where not built or tested on 32 bit machines. To build the sources as a regular user I needed to add myself to the /etc/sudoers file. This was done by switching to root, running the visudo command and adding the following line to the end of the file.

stephen ALL=(ALL) ALL

After adding the line I then saved the file and exited the root shell.


The next step was to create the build environment using the rpmdev-setuptree command. Since I knew which programs I wanted to build into RPM’s I moved to the directory ~/rpmbuild/SOURCES and then downloaded the sources file into there with the commands below.




I then moved into the SPECS directory and created the spec file for each application. The macchanger spec file was pretty straight forward to build with a few simply fixed errors during the rpmbuild stage and the rpmlint stage.

Build Errors encountered during rpmbuild -ba macchanger.spec

Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/stephen/rpmbuild/BUILDROOT/macchanger-1.5.0-1.fc13.x86_64

error: Installed (but unpackaged) file(s) found:







Fixed error by adding under the %file directive






Errors encountered with the rpmlint -i  RPMS/x86_64/macchanger-1.5.0-1.fc13.x86_64.rpm


macchanger.x86_64: E: no-changelogname-tag

macchanger.x86_64: E: info-files-without-install-info-postin /usr/share/info/

macchanger.x86_64: E: info-files-without-install-info-postun /usr/share/info/

macchanger.x86_64: E: info-dir-file /usr/share/info/dir

macchanger.x86_64: E: info-files-without-install-info-postin /usr/share/info/dir

macchanger.x86_64: E: info-files-without-install-info-postun /usr/share/info/dir



The 6 errors where fixed by adding the information below  to the spec file. The first 2 line where added to the header of the spec file and the rest of the lines where added after the %install directive and these lines fixed errors 2, 3, 5, and 6

Requires(post): /sbin/install-info

Requires(preun): /sbin/install-info



/sbin/install-info %{_infodir}/ %{_infodir}/dir || :0



if [ “$1” = 0 ]; then

/sbin/install-info –delete %{_infodir}/ %{_infodir}/dir || :



Adding the following line to the end of commands under the %install directive fixed the 4th error

rm -f $RPM_BUILD_ROOT/%{_infodir}/dir


Adding the following lines below the %changelog section fixed the 1st error

* Sat Jan 15 2011  <> 1.5.0-1

– Initial Packaging of macchanger


The process was pretty much the same for the wget program as well, there were less errors during the process because I modified the wget.spec file to fix the same errors that I ran into with macchanger program before trying to build. I also used the spec file from the wget SPRM to determine what the build requires because I had not learnt about mock at the time. The only other thing that I had to do was add the line below to the spec file under the %file directive so that it could build with the language files.




The RPM’s and SRPM’s are available for download from the links below.




I am Stephen a 6th semester student i the CTY program at Seneca. I am mainly interested in security and networking, but I believe this course will be useful and an interesting learning experience.
Email: sahall3[at]learn. senecac. on .ca
IRC Nickname:  sahall3
Seneca Wiki
Fedora Wiki

IRC Chat Excerpt:
<sahall3> perfect they upgrade the wireless network in time for us to graduate.
<ThaFuzz> perfect timing, just as we finish our final semester york will be getting a subway stop and new wireless
<ctyler> I’ve wondered if all this is temporary, that the idea of the school providing wireless will be as obsolete as the fact that the school used to provide dial-up networking — I think in a few years everyone might just be on 4G (or 5G?)
<sahall3> i will believe that when it happens
<t0mmyw> just in time for next years FSOSS.  🙂
<{{localhost}}> sahall3: what did they upgraded it to? 802.11g?

Software chosen to build from source was macchanger, I had to install gcc with yum install to be able to compile macchanger