Playing around with GIT

"Git is distributed version control system focused on speed, effectivity and real-world usability on large projects." It's a wonderful tool for individual developers to work on codes in a peer-to-peer approach.

I still have yet to try more about Git, but for now I'll show how Git can be used as a tool that can backtrack any progress when working on some local files.

Here's how I played around Git:

I created a parent directory called testplay which contains a directory for the nled package.
All the commands that follow are done inside the testplay directory.

To let Git take revision control of the directory, I typed:

#git init

Git initializes with the message "Initialized empty Git repository in /home/user/testplay/.git/"

So far Git has no idea about the files or "lines" that it will track. In order for Git to have a snapshot of the directory, 2 commands are needed:

#git add .

AND

#git commit

This enables Git to store the snapshot permanently in the repository. Every commit creates a version (When commit is run, Git automatically takes the user to Vi editor for a commit message).

Alternatively, using git commit -a does the same purpose as git add and git commit.

Branches

The snapshot/version I created was made under a "branch" named "master" by default. Any commits will update this branch. Git can have multiple branches. Branches are names that points to a particular commit. Given are the commands used to best explain what branches are and what they do.

Display the branches in the repository

#git branch

In my case, I only have 1 branch so the output shows:
* master (where the "*" tells the user that the master branch is active.)

Create another branch from the master branch

#git branch extend1

Git now has 2 branches. I can now create 2 versions of my project based on these branches. A commit or change in one branch wouldn't affect the other unless merged.

To make a desired branch active (In my case 'extend1'):

#git checkout extend1

Produces a message: "Switched to branch 'extend1'"

I created a random file inside the nled/ directory and ran the git add and git commit. If I go back to my "master" branch, the file I created wouldn't be visible; this approach is very useful for debugging and testing out program compilations. :)

Useful Links

Official Git page
gittutorial page
gitmagic

Optimizing a package for ARMv7 architecture

This is part of the 0.1 stage of Supporting Architectures above armv5tel project. I need to test an optimized package for BeagleboardXM-ARMv7 architecture and document the results. Packages are needed to be optimized to take advantage of ARMv7 processor features namely:

• Thumb®-2/ Thumb
• NEON™
• VFPv3 Floating Point

I was supposed to test my compile on cdot-beagleboardXM-0-3 yesterday and today, but it’s down because the adapter is loaned out.

Anyway, I’ll just show my compiler optimization options and would appreciate any comments.

Compiling a package using ARM specific optimization option (using GCC 4.4.x):

CFLAGS="-O2 –march=armv7-a –mtune=cortex-a8 –mfpu=neon
–mfloat-abi=hard –fomit-frame-pointer"

*Using -mfloat-abi=hard with VFP coprocessors is not supported. Use -mfloat-abi=softfp with the appropriate -mfpu option to allow the compiler to generate code that makes use of the hardware floating-point capabilities for these CPUs. I would have to use this in any case -mfloat-abi=hard doesn't work

Optimization definition:

-O2
-O2 turns on all -O optimizations and all other optimizations that don't greatly increase binary size or interfere with debugging. -O2 is even better than -O, and usually just as safe. This is the optimization level most commonly used for packages and distributions in the Linux world and for the Linux kernel.

-march=your_arch
-march= tells gcc to optimize for a certain architecture. Basically, you just need to know what your CPU is, and the GCC name for it. This may break compatibility with other architectures!

-mtune=/-mcpu=
-mtune=, or -mcpu in older versions of GCC, is similar to -march and accepts the same options. Unlike -march it doesn't break compatibility with older arches. -march and -mtune/-mcpu options can be mixed to get the desired effect.

-mfpu=name
This specifies what floating point hardware (or hardware emulation) is available on the target.

-mfloat-abi=name
Specifies which floating-point ABI to use. Permissible values are: `soft', `softfp' and `hard'.

Specifying `soft' causes GCC to generate output containing library calls for floating-point operations. `softfp' allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions. `hard' allows generation of floating-point instructions and uses FPU-specific calling conventions.

-fomit-frame-pointer
-fomit-frame-pointer tells gcc to omit frame pointers, freeing up an additional register on the CPU. This is mainly useful on x86 as most other arches, like AMD64, have it on by default at -O2 or greater, though binary size may increase slightly. This flag breaks debugging on x86 and possibly other arches unless you're compiling with gcc 4.x and the -fvar-tracking flag.

Sources:

CFLAGS Definition
GNU Compiler Collection
GCC ARM Options
Armin76's Blog

I would like to extend my thanks to the people on IRC and the community Including Chris Tyler and Paul Whalen for guiding me in this project.

#seneca
#fedora-arm
#ubuntu-arm
#gentoo-embedded

Documentation is still on process, the test results will be posted by next week:

FSOSS 2010 - Day 2 (October 29, 2010)

I wasn't able to blog last Friday (October 29, 2010) due to my sickness. After my volunteer shift around 3:00PM that day, I started feeling lightheaded. I rushed home and skipped my awaited presentation (Paul Whalen's ARM Project). As soon as I got home, I crashed into bed and had a fever later that night.
I'm feeling a little better now. I hope I don't miss tomorrow's SBR600 class due to this.


Here are the presentations I attended to last Friday:

The Business of Linux - How individuals can get in the game
It's an hour talk about the basics of business practices do's and don'ts. It was presented by Ms. Karlie Robinson.

Systemtap - System Wide Probing on Linux: Focus on User Space
I personally think this is an awesome project, but I didn't really get how they presented it. I don't know if I was just not techie enough or it was just too technical. It was presented by Mr. Dave Brolley and his team of 2 guys (names didn't appear on the presenter list)

How CMS architectures affect dev. communities
I was expecting too much for this presentation. I thought I was going to find out which CMS system is the most popular, widely used... etc. Although the presentation only lasted for 30 minutes I still learned about architectures, programming languages used and a little about Content Management System evolution. It was presented by Mr. Julian Egelstaff.

Useful Links:

Karlie Robinson's Blog.
Systemtap

FSOSS 2010 - Plug Computing Workshop (October 28, 2010)

Since I started in my program, I never missed a single FSOSS event. I can't find any reason not to join; It's cheap, I learn things that for sure won't be available anywhere else, and lastly..FREEBIES!! Of all the FSOSS events, workshops have always been what I like the most. Today I showed up for Chris Tyler's Plug Computing Workshop.

The workshop covered everything from setting up the GuruPlug to creating a personalized image server. I'm convinced on how powerful ARM PCs are, so I'm considering of getting one and probably experiment on it.

As always, workshops include Q&A part. I never had a chance to ask any question but I learned from Chris some important things to know about the GuruPlug and similar ARM based plug computers

• GuruPlugs have problems with Gigabit Ethernet (slows down for some odd reason)
  
• Overheat problems (the reason why it's got a fan in the middle)
  
• GuruPlugs consume electricity comparable to a radio clock
  

Useful Links:
PandaBoard
BeagleBoard
SheevaPlug

The day I learned about Python

Chris Tyler discussed a little bit about Python today for my classmates working on projects that include moderate to heavy scripting. I'm not really good at programming languages but I always find myself interested to learn about it.

As soon as I got home, I hurriedly turned on my PC and wrote my first Hello World in Python. Sir Chris told me last Thursday when I asked him which programming language will stand out the most in the near future, He replied... "Python".
I definitely agree to what he said; Considering some popular software embed/use Python.

Anyway I'm interested in learning more so I downloaded my copy of "Dive into Python".

Regarding the ARMv7 Project, I haven't had a time this week. I still need to catch up on my readings.

Details about the ARMv7 Project

I had a great time talking to Chris Tyler yesterday about the ARMv7 Project. He explained the tests needed for the project and briefly contrasted ARMv5 & ARMv7.

My project details include:
-Working on the cdot-beagleXM-0-3 host
-Study the make command and the gcc compiler
-Compile software under ARMv7

Just a quick info:
cdot-beagleXM-0-3 is an ARMv7 board that tests ARMv5 architecture builds. What does that mean?? I can't think of any good analogy but this.. It's like running an old PC game on a NEW computer. It will work, but without the enhanced features on.
With that said, my project will try to test if the technologies in ARMv7 provide significant performance difference against ARMv5.

BeagleBoard XM image

More About ARM and BeagleBoard
BeagleBoardXM
List of ARM processors
Supporting Architectures above armv5tel Project Page

Using Mock & Koji

After wasting 2 weeks of trying to build my own spec file from scratch, It's a pain to say that I need more time to fully understand some of the macros used in my privoxy build. privoxy's spec file although short, has lines meant for advanced builders. It's a real challenge for a noob builder like me!! :)

On the brighter side, building a spec for nled walked me through the basics I need. The "How to Create an RPM Package" and the "Maximum RPM" are both good resources.

Using Mock

The "Using Mock to test package builds" page has all the instructions and links needed for a successful mock build (In which I noticed that my build was slower compared to using rpmbuild-ba). I also followed the instructions for setting up SELinux policy for mock.

Using Koji

Using Koji in Fedora is also pretty straight forward. Setting up my certificates and uploading my build didn't take long.

Here's an image of my build status:

Lastly....

I'm putting off my tests for rpms to work on the armv7tel project. I only have a project page draft for now, but I'll make sure to document everything.

Details on my armv7tel project can be viewed here