Jumat, 06 September 2013

Xathrya Sabertooth

Xathrya Sabertooth


How to Setup Arch Linux ARM Repository Manually

Posted: 06 Sep 2013 02:28 AM PDT

Arch Linux ARM is a Linux operating system distribution for ARM architecture. This distribution is one of recommended OS for Raspberry Pi board.

By default, Arch Linux ARM has a global repositories. On some point, the repository can redirect your pacman to appropriate (other) repository based on your location. But sometimes, it’s not enough.

In this article, we will discuss about how to change ArchLinux ARM repository manually.

Preparation

Make sure your Pi has Arch Linux ARM inside. You should also make sure your Pi can connect to internet.

You need to acquire root privileges. We need root privileges to edit pacman configuration file.

Configuration

First see the /etc/pacman.d/mirrorlist and search location closest to you. If you see a preferrable repository, you can start edit this file.

Comment out line under “Geo-IP based mirror selection and load balancing”:

# Server = http://mirror.archlinuxarm.org/armv6h/$repo

and uncomment the mirror server you choose, for example I choose Finland:

Server = http://fi.mirror.archlinuxarm.org/armv6h/$repo

If you have another mirror which are not listed there (you have to really sure about it), you can comment out every line and add new line at the bottom. For example, the mirror server is http://archarm.xathrya.web.id, then you write following line:

Server = http://archarm.xathrya.web.id/armv6h/$repo

Arch Linux Pacage Manager Command List

Posted: 06 Sep 2013 02:25 AM PDT

Here is the list of useful commands for pacman. Pacman is a package manager for Arch Linux.

Whether you use x86, amd64, or ARM architecture, the command should remain same.

Upgrade Packages

This will update all packages on the system.

pacman -Suy

Perform Full Upgrade

This is necessary if some libraries are missing to recompile system properly.

pacman -Syyu

Install New Package

Install specific package.

pacman -S $PACKAGE

where $PACKAGE is the package name you want to install. For example: xorg-server

Install package groups

pacman -Sg $PACKAGEGROUP

where $PACKAGE is the package group. For example: gnome.

Remove Package

Remove package, normally.

pacman -R $PACKAGE

where $PACKAGE is the package name you want to remove. This will remove a single package and leaving all of its dependencies installed.

If you want to remove a package and its dependencies which are note required by any other package, do following:

pacman -Rs $PACKAGE

If you want to remove a package, its dependencies, and all of the dependent (packages depend on it)

pacman -Rsc $PACKAGE

Search for Package

Will search the package database on given keyword

pacman -Ss $KEYWORD

where $KEYWORD is the keyword, can be parts of package name, description, etc.

List of Package Installed

List of packages

pacman -Q

List the package installed with given keyword

pacman -Q | grep $KEYWORD

List the packages installed as dependencies but not used anymore.

pacman -Qdt

List the packages installed, and not needed by other packages (not bein depended on)

pacman -Qet

List of files installed with package (content of package)

pacman -Ql $PACKAGE

Creating Echo Server on Raspberry Pi using Haskell

Posted: 05 Sep 2013 07:02 AM PDT

Haskell is one of powerful functional programming language. More specific, it is a polymorphically statically typed, lazy, purely functional language. It is the good language for expressing math equation and logic naturally. Haskell is based on the lambda calculus, thus it use lambda as the logo.

Despite of functional paradigm nature, Haskell is very good for network and distributed system application. It can also applied as application on cloud computing.

After installing haskell on Raspberry Pi, it is worth to test what Haskell can do. This article will discuss about creating a simple Echo Server on Raspberry Pi using Haskell programming language.

In this article I use:

  1. Raspberry Pi model B 512MB RAM
  2. Raspbian Wheezy 2013-07-26 hardfloat

Overview

What we really want to build in this article is a modified Echo server. This program will run forever (infinite loop) and listen on port specified by user when invoking program. Like any socket-based application, when a connection come, it will accept and process it according to our app’s logic. Our logic is so simple. Whenever user connect to server using telnet, this server will echo every line they write (echo). However when they write “ping” without quote, the server will reply with “pong”.

Preparation

Make sure you have install Haskell on your Pi.

Writing code to Pi can be done using any method. You can access your Pi remotely or access directly. At least, make sure you can create a file and write it.

Writing the Code

Write this snippet and save it as “echoserver.hs”:

import System.Environment (getArgs, getProgName)  import Control.Concurrent (forkIO)  import Network (Socket, PortID(PortNumber), withSocketsDo,          listenOn, accept)  import System.IO (hPutStrLn, hGetLine, hFlush)  import Control.Monad (forever)    main = withSocketsDo $ do      args <- getArgs      prog <- getProgName      case args of          [port] -> do              socket <- listenOn $ PortNumber (fromIntegral (read port :: Int))              putStrLn $ "Listening for pings on " ++ port              handleRequest socket          _ ->              putStrLn $ "usage: " ++ prog ++ " <port>"    handleRequest s = do      (handle, _, _) <- accept s      forkIO $          forever $ do              input <- hGetLine handle              processPing (hPutStrLn handle) (init input)              hFlush handle      handleRequest s    processPing f msg = do      if msg == "ping" then           f "pong!"          else              f msg

Also, make sure you pay attention to the indentation.

This code is simple and should run on any architecture supported by GHC, including our Pi.

Build and Testing

To build the above code, run this command (assume the code is saved as echoserver.hs):

ghc -O2 --make echoserver.hs

The -O2 flags are used to apply every non-dangerous optimization, but might make the compilation time longer.

After compilation successful, you will have a new file name echoserver. To run the server do this on your Pi:

./echoserver 5000

This will run a server and make it listen to port 5000.

Now on your local computer, open up command prompt / terminal and invoking telnet to connect to your Pi. Suppose our Pi is on address 192.168.1.11, do following:

telnet 192.168.1.11 5000

which will connect us to Pi on port 5000.

You can test by write any line there. Good luck :)

Installing ARM Development Studio 5 – Community Edition

Posted: 05 Sep 2013 06:33 AM PDT

ARM Development Studio 5 is one of the development studio used for cross compiling and developing application for ARM processor. ARM DS-5 is developed by the very expert one on ARM architecture and enable engineers to develop robust and highly optimized embedded software for ARM application processors. The DS-5 toolchain comprises tools such as the best-in-class ARM C/C++ Compiler, powerful Linux/Android/RTOS-aware debugger, ARM Streamline system-wide performance analyzer, and realtime system model simulators. All conveniently packaged in a user friendly integrated development environment (IDE) based on the Eclipse.

In this article we will discuss about how to install ARM Development Studio 5 Community Edition on various operating system.

This article is written based on following:

  1. Slackware64 14.0
  2. Windows 8
  3. JDK 1.7

If you don’t want create a cross compile toolchain by yourselves, this method is suitable for you.

Requirements

ARM Development Studio 5 requires Java, JRE or JDK. You need this package to run the IDE (Integrated Development Environment), which is a modified Eclipse.

Obtain Materials

Download the ARM DS-5 by visiting this page. There are four types of installer:

  1. Windows 32-bit
  2. Windows 64-bit
  3. Linux 32-bit
  4. Linux 64-bit

Make sure you download the appropriate package for your system.

Installation

I assume you have downloaded the package specific to your platform. Follow the section which suit your platform:

Windows

Aside from the target architecture you download, you should have a zip file with .zip extension. You shall have following items:

  1. Guide e-book (ds-5_license_management_guide.pdf)
  2. ARM logo (armlogo.png)
  3. change log (changes.html)
  4. readme (readme.html)
  5. actual installation file (install_<yourplatform>.exe)

Extract the package and do the installation by running the file.

Linux

Aside from the Linux target version for the package you download, you should have a tar ball package with .tgz extension. Inside you will have following:

  1. Guide e-book (ds-5_license_management_guide.pdf)
  2. ARM logo (armlogo.png)
  3. change log (changes.html)
  4. readme (readme.html)
  5. actual installation file (install_<yourplatform>.sh)

We will refer the installation file as install.sh.

Extract the packages to any directory and make sure you are currently accessing the top directory of the package content.

Change to root account or account with root privilege.

Do installation by executing the install.sh

./install.sh

You will be asked some questions. The questions are straightforward, nothing tricky here. Install it to any location you want. For example, I choose /usr/local.

Once installed, you will have ARM Development Studio installed on /usr/local/DS-5 if you choose /usr/local. You then will be asked to add /usr/local/DS-5/bin to your PATH. Do this by editing your shell startup script (ex: .bashrc).

To start IDE, you can run /usr/local/DS-5/bin/eclipse.

You can also invoke toolchain without running the Eclipse IDE.

The Flash File System

Posted: 05 Sep 2013 06:23 AM PDT

You might have ever heard of Journaling Flash File System (JFFS) and Yet Another Flash File System (YAFF), both are file system that underlying flash device. These file system mostly used in embedded employing flash memory technology. Flash file system considers the special abilities, performance, and restrictions of flash memory device.

This article will discuss about Flash File System, the technology behind, and implementation.

Flash Memory Technology

There are several different technology for Flash Memory categories. But, all the technologies are non-volatile memory, which the content can persist after the power source is removed. It’s like magnetic-based storage system such as Hard Disk, but using flash memory instead.

Two of the most common type of flash memory are: NOR and NAND. NOR-based flash is the older technology. It supports high read performance at the expense of smaller capacities. NAND flash offers higher capacity with faster write and erase performance. NAND also requires a much more complicated input/output (I/O) interface.

Flash parts are commonly divided into partitions, which allows multiple operations to occur simultaneously (erasing one partition while reading from another). Partitions are further divided into blocks which might be 64KB or 128KB in size. Firmware that uses the partitions can further apply technique segmenting to the blocks.

Flash devices exhibit a common constraint that requires device management when compared to other storage devices such as RAM disks. The only Write operation permitted on a flash memory device is to change a bit from a one to a zero. If the reverse operation is needed, then the block must be erased (to reset all bits to the one state). This means that other valid data within the block must be moved for it to persist. NOR flash memory can typically be programmed a byte at a time, whereas NAND flash memory must be programmed in multi-byte bursts (typically, 512 bytes).

The process of erasing a block differs between the two memory types. Each requires a special Erase operation that covers an entire block of the flash memory. NOR technology requires a precursor step to clear all values to zero before the Erase operation can begin. An Erase is a special operation with the flash device and can be time-consuming. Erasing is an electrical operation that drains the electrons from each cell in an entire block.

NOR flash devices typically require seconds for the Erase operation, whereas a NAND device can erase in milliseconds. A key characteristic of flash devices is the number of Erase operations that can be performed. In a NOR device, each block in the flash memory can be erased up to 100,000 times. NAND flash memories can be erased up to one million times.

The Challenges

In addition to and as a result of the constraints explained in previous section, managing flash devices has several challenges. Three most important are: garbage collection, managing bad blocks, and wear leveling.

Garbage Collection

The process of reclaiming invalid blocks. The invalid blocks are block which contain some amount of invalid data. Reclamation involves moving the valid data to a new block, and then erasing invalid block to make it available. This process is commonly done in the background or as needed, if the file system is low on available space.

Managing Bad Blocks

Over time, flash devices can develop bad blocks through use and can even ship from the manufacturer with blocks that are bad and cannot be used. The bad blocks may occur from a failed flash operation (such as an Erase) or an invalid Write operation (discovered through an invalid Error Correction Code, or ECC).

After bad blocks have been identified, they are marked within the flash itself in a bad block table. How this is done is device-dependent but can be implemented with a separate set of reserved blocks managed separately from normal data blocks. The process of handling bad blocks—whether they ship with the device or appear over time—is called bad block management. In some cases, this functionality is implemented in hardware by an internal microcontroller and is therefore transparent to the upper-level file system.

Wear Leveling

Like any device, you cannot use flash memory forever. Flash memory has finite limit of Erase cycles on each blocks before the block becomes bad. To maximize the life of the flash, wear-leveling algorithms are provided. Wear leveling comes in two varieties: dynamic wear leveling and static wear leveling.

Dynamic wear leveling addresses the problem of a limited number of Erase cycles for a given block. Rather than randomly using blocks as they are available, dynamic wear-leveling algorithms attempt to evenly distribute the use of blocks so that each gets uniform use.

Static wear-leveling algorithms address an even more interesting problem. In addition to a maximum number of Erase cycles, certain flash devices suffer from a maximum number of Read cycles between Erase cycles. This means that if data sits for too long in a block and is read too many times, the data can dissipate and result in data loss. Static wear-leveling algorithms address this by periodically moving stale data to new blocks.

System Architecture

For Operating System perspective (in our example, Linux) the filesystem based on flash memory technology has similar abstraction as other file system. The difference might exists in lower level, where the hardware addressing the storage system.

As seen on figure below, at the top is the virtual filesystem (VFS), which presents a common interface to higher-level applications. As controlled by same abstraction, user-space application can address flash memory like any other storage.

figure1

The VFS is then followed by the flash file system, which will be covered in the next section. Next is the Flash Translation Layer (FTL), which provides for overall management of the flash device including allocation of blocks from the underlying flash device as well as address translation, dynamic wear leveling, and garbage collection. In some flash device, a portion of the FTL can be implemented in hardware.

The Linux kernel uses the Memory Technolody Device (MTD) interface, which is a generic interface for flash device.

Flash File System

Journaling Flash File System (JFFS)

One of the earliest flash file system. It is a log-structured file system that was designed for NOR flash devices. It was unique and addressed a variety of problems with flash devices, but it created another.

figure2

JFFS viewed the flash device as a circular log of blocks. Data written to the flash is written to the tail, and blocks at the head are reclaimed. The space between the tail and head is free space; when this space becomes low, the garbage collector is executed. The garbage collector moves valid blocks to the tail of the log, skips invalid or obsolete blocks, and erases them (see Figure 2). The result is a file system that is automatically wear leveled both statically and dynamically. The fundamental problem with this architecture is that the flash device is erased too often (instead of an optimal erase strategy), which wears the device out too quickly.

When a JFFS is mounter, the structural details are read into memory. This can be slow at mount-time and consume more memory than desired.

Journaling Flash File System 2 (JFFS2)

The successor of JFSS to address JFSS limitation. The wear-leveling algorithm of JFSS tends to shorten the life of NOR flash device. The first JFFS2 was designed for NAND flash devices and also includes improved performance with compression.

In JFFS2, each block in the flash is treated independently. JFFS2 maintains block lists to sufficiently wear-level the device. The clean list represents blocks on the device that are full of valid nodes. The dirty list contains blocks with at least one obsoleted node. Finally, the free list represents the blocks that have been erased and are available for use.

figure3

The garbage collection algorithm can then intelligently decide what to reclaim in a reasonable way. Currently, the algorithm probabilistically selects from the clean or dirty list. The dirty list is selected 99 percent of the time to reclaim blocks (moving the valid contents to another block), and the clean list is selected 1 percent of the time (simply moving the contents to a new block). In both cases, the selected block is erased and placed on the free list (see Figure 3). This allows the garbage collector to re-use blocks that are obsoleted (or partially so) but still move data around the flash to support static wear leveling.

Yet Another Flash File System (YAFFS)

Another flash file system for NAND flash. The initial version of YAFFS support flash device with 512 byte pages. The newer version has support newer devices with larger page sizes and greater write constraints.

figure4

In most flash file systems, obsolete blocks are marked as such, but YAFFS2 additionally marks blocks with monotonically increasing sequence numbers. When the file system is scanned at mount time, the valid inodes can be quickly identified. YAFFS also maintains trees in RAM to represent the block structure of the flash device, including fast mounting through checkpointing —the process of saving the RAM tree structure to the flash device on a normal unmount so that it can be quickly read and restored to RAM at mount time (see Figure 4). Mount-time performance is a great advantage of YAFFS2 over other flash file systems.

Running Haskell on Raspberry Pi

Posted: 05 Sep 2013 06:15 AM PDT

Haskell is one of powerful functional programming language. More specific, it is a polymorphically statically typed, lazy, purely functional language. It is the good language for expressing math equation and logic naturally. Haskell is based on the lambda calculus, thus it use lambda as the logo.

Haskell can be installed on various operating system, from Linux, Windows, Mac OS. Most of them are Operating System for Personal Computer (PC). Now, can we install Haskell to different platform? ARM maybe? Yes it can.

In this article we will discuss about how to install Haskell on top of Raspberry Pi device. Specifically, the Raspberry Pi device which running Linux OS. The device I use as test is Raspberry Pi model B with 512MB RAM.

Preparation

Make sure you have a good preparation. You have downloaded Raspberry Pi’s OS images and write to your SD card. Therefore, I assume you have install Linux operating system on your Raspberry Pi.

There is no special treatment for installation. I assume you have a ready to play Pi with network support.

You can either use SSH or connect some peripheral (keyboard, mouse, display) to access Pi. We won’t cover much detail here.

Theory Behind

There are two package we will discuss on this article: ghc and haskell-platform.

GHC or Glasgow Haskell Compiler, is a package with compiler, and interactive interpreter for Haskell.

Haskell-platform is a platform, has a collection of haskell code and tools for developing Haskell application.

Installation

on Raspbian Wheezy

The raspbian I use here is 2013-07-26. To install Haskell on Raspbian, use:

# make sure you have root privilege to install  sudo apt-get install ghc haskell-platform

If you take it correctly, you has already install Haskell. It should be no problem at this point.

The real problem might occur here. The ghc used on Raspbian (per September 5th, 2013) are version 7.4.1 and according to Haskell official site ghci or the interpreter cannot be used for version lower than 7.4.2 on ARM based device.

Tidak ada komentar:

Posting Komentar