The Linux Blog UNIX, LINUX, BSD, OSX

23Feb/092

Linux Mint 6 x64 released!

This release comes with all the innovations featured in Linux Mint 6 Felicia and for the very first time with the 64 bit versions of the Adobe Flash and Sun Java plugins!

Introduction to the x64 edition:

The purpose of the x64 edition is to offer the same desktop features as the Main edition but in a 64 bit environment. It aims to be as similar to the Main edition as possible.

More packages are available for i386 than they are for amd64 and the Main edition is also slightly more stable than its 64 bit equivalent. The Main edition only recognizes a maximum of 4GB RAM though and even on computers with less than 4GB RAM the performance gain provided by x64 over the Main edition can significantly enhance the user’s experience.

System requirements:

An X86_64 64 bit processor (Intel Core 2, AMD X2 64, etc…) .

A minimum of 512MB of RAM is recommended. Once installed the system works fine with as low as 256MB RAM. The installation process deals with 2.5GB of data compressed on a 700MB CD and it can hang or fail on systems with less than 512MB RAM. If you have between 256MB and 512MB RAM you may have to try to install several times.

Download Linux Mint 6 x64:

Europe:

Northern America:

Rest of the World:

Order Linux Mint 6 x64 on CD:

You can order Linux Mint 6 x64 on CD from our partner on-disk.com:

http://on-disk.com/product_info.php/cPath/28_153_277/products_id/612

Tell us what you think:

Depending on your hardware x64 Edition could be faster and show better performance than the Main edition. We’re interested to know how both editions compare so don’t hesitate to measure your boot time, and common scenarios and compare them on the same computer with the Main edition.

Changes since x64 RC1:

If you’re currently running Linux Mint 6 x64 RC1 you do not need to install the stable release. To get the 64 bit versions of Flash and Java, type the following commands in a terminal:

  • apt remove –purge flashplugin-nonfree nspluginwrapper
  • apt update
  • apt install mint-meta-x64

Also note that mint4win doesn’t work on the RC1 CD and that it does on the stable one.

Have fun!

Have a lot of fun with the x64 Edition and thank you for running Linux Mint.

Via: www.linuxmint.com

22Feb/090

Nokia E55 short review

We sniffed out Nokia's new E55 not-a-QWERTY QWERTY candybar phone, which uses a SureType-esque predictive text mechanism with two letters per key, and looks pretty good doing it. Nokia's calling this the "world's thinnest smartphone," quite the feat if it's true, and it might just give Nokia's ultrapopular E71 a run for its money in the "fashionably smart" category. We played with the phone for a brief moment, and though it's running an alpha software build, we didn't have much trouble typing out a quick message.

Unfortunately, while the keys are naturally larger, they aren't very "clicky" or distinct -- not horrible, but certainly not best-in-class. The prediction works well enough, learning new words after one entry, and letting you d-pad up and down through other options if it doesn't get it right the first try. Overall the phone feels on par with quality of the E71, though lighter and smaller, and is insanely pocketable.

All article via engadget.com

Tagged as: No Comments
20Feb/090

Nokia signs €500 million loan for Symbian R&D

You'd think a company like Nokia could just finance whatever it wanted, but just to be safe, it's signing a loan agreement with the European Investment Bank (EIB) to the tune of €500 million ($623.9 million). Why the sudden need for cash?

According to Reuters, the five-year loan will be used in part to "finance software research and development (R&D) projects Nokia is undertaking during 2009-2011 to make Symbian-based smartphones more competitive." More specifically, those R&D activities will "also benefit the work of the Symbian Foundation and its development of open-source software for mobile devices." Sadly, that's absolutely it for details, but we get the idea we'll be hearing more about this soon. We hear you can accomplish some pretty wild goals with a half billion Euros.

Filed under: IT Magazine No Comments
20Feb/090

Windows Mobile 6.5 screenshots have a little Zune in ‘em

Windows Mobile 6.5 was just a whisper on a Motorola phone chief Sanjay Jha's lips two weeks ago, but now that Ballmer himself has confirmed that there's at least one more rev of WinMo 6 en route before Windows Mobile 7 hits it looks like the floodgates have opened -- check out these hot screenshots, one of which seems to have been liberally dipped in Zune sauce. We're hoping that means we'll see some Zune integration with this next generation of handsets, but we're not going to get too worked up yet (cough, Xbox). It does look quite nice, though, and we've got our fingers crossed that this revamp is more than just a pretty new home screen and app launcher -- you're way late to that party, Microsoft. No telling on when 6.5 will actually get here, but Ballms said it'll be sometime next year, so we're guessing we don't have too long to wait.

Update: As several of you have pointed out, some of the icons are a little suspicious -- that "Today" icon is OS X's Home icon, for example. We're hoping this is the real deal and not just a user-made skin, but we wouldn't start making any long term plans here.

Filed under: IT Magazine No Comments
5Feb/090

Chrome 2.0 beta but no Linux version, yet

Google released a pre-beta version of its Chrome 2.0 browser late last week but has still not made a Linux or Mac version of the browser available.

The 2.0 version of the browser was released to developers and includes a number of new features including the begins of an extension strategy for the browser.

Senior Google staffers said, however, that Linux and Mac versions of the browser would only be made available later this year. CNet quotes Brian Rakowski, Chrome’s product manager, who said that the Mac and Linux versions of the browser were now at the “test shell” stage which meant that they could show web pages but are still in a very raw format.

Rakowski said that versions of Chrome for Linux and Mac would likely be made available by the middle of 2009.

Extensions

Chrome 2.0 pre-beta does include support for some extension scripts, which will pave the way for fully-fledged extensions in the near future. Extensions are among the most requested features from users and is a key part of the success of rival browser Firefox.

Other new features in version 2.0 of Chrome include autocomplete for web forms, full-page zoom, multiple browser profiles each with their own bookmarks and cookies, autoscroll using the mouse centre button and the ability to import bookmarks from the Google Bookmarks site.

Less obvious to users but key to Chrome 2.0 is the inclusion of a new version of the WebKit rendering engine. The new Chrome release uses WebKit 528.8, which is faster and supports features such as CSS canvas drawing for 2D shapes such as lines on maps or custom-generated charts.

Source: http://www.tectonic.co.za

Tagged as: , , , No Comments
5Feb/090

Hands on with Firefox’s mobile browser

A couple of weeks ago we wrote that a mobile edition of Firefox was expected within weeks. Well, here’s an alpha version of Fennec. We decided to give the little fox a spin to see what exactly the Firefox team had been up to over the past few months.

At this point Mozilla has only released an alpha version of Fennec, the name given to the mobile version of Firefox. And as such it is a little buggy, but many of the expected features are already in place and working.

Fennec right now is only available for a single mobile device, the Nokia 810 tablet, although a version is also available for testing on Linux, Mac and Windows. Of course the desktop version doesn’t do the touch screen capabilities any justice but for an idea of what to expect when Fennec does hit your mobile, read on.

Interface

The first thing when you open Fennec is the simple and clean layout. There is the address bar across the top of the screen and the rest of the space is dedicated to the browser.

The address bar is well implemented and like the desktop Firefox browser responds to partial words typed into the bar. Most often this based on your browsing history which is pulled up on the screen below. If none of those is your intended destination then hit enter and Fennec searches on Google by default.

The one thing on a mobile device you don’t want to do a lot of is typing so Fennec’s attention to detail in this area could of crucial importance.

With a page loaded in the browser window you can scale this up or down to fit either a piece of the website in the window or the entire page.

Where are the buttons?

The initial Fennec window is clean. So clean that you’re probably wondering where all the controls are. This is where the touch screen comes in. Swipe from the right to the left and you’ll see a basic set of tools appear. In the right hand bar you’ll find the back and forward buttons as well as the “star” which can be used to bookmark websites. Down at the base of the right bar you’ll see a cog icon which opens up the basic settings window.

Right at the top of the right hand bar you’ll see a jigsaw icon. Clicking on this brings up a familiar extensions manager. In the alpha release this is still pretty much empty although there are a handful of standard plugins - things like Adobe reader.

One of the nice features in Fennec is the horizontal movement. For example, one swipe to the left exposes the tool bar. Clicking on the settings button slides the browser window even further across. To get back, two swipes to the right closes those windows.

Tabbed browsing

The same is true of the left hand bar. Swipe across the screen from left to right and you’ll find Fennec’s version of tabbed browsing. In the left hand bar there are icons of the pages you already have open, as well as a “plus” icon to open a new “tab”. Helpfully, each “tab” has a close button attached to it so you can close any existing window without having to actually open it.

It is still early days with Fennec, but this alpha release makes it look very promising. The interface is clean and simple and with a touchscreen promises to be easy to use, but we’ll have to wait until we get our hands an a Nokia tablet before we can say for sure.

Give Fennec a spin and let us know what you think in the comments.

Source: http://www.tectonic.co.za

5Feb/090

Acer to ship 10-inch Aspire One with Linux

Despite earlier announcing that it would only ship a Windows XP version of its 10-inch Aspire One netbook, Acer now says it plans to release a Linux version as well.

A company spokesman said this week that the 10-inch Aspire One would soon be available with Windows XP or Linux and a choice of a 160GB hard disk drive or a 16GB solid state drive.

Acer’s original Aspire One had an 8.9-inch screen and a choice of Windows XP or Linupus, Acer’s customised Linux operating system. The Aspire One 10-inch is expected to be released in mid-February internationally.

Reports of pre-orders in the US pin the Aspire One 10-inch at $349. SA pricing and availability are not known at this point.

Source: http://www.tectonic.co.za/?p=3962

4Feb/091

Burning Cd using Linux command Line

Introduction

I suppose here you got mkisofs, cdrecord and cdrdao What you need ?
- CD-Drive
- a CD-RW

We have to check the device of our drive(dev) to burn Cd using command Line,

For Linux Kernels 2.6.x, we got:

# cdrecord -scanbus dev=ATA
Cdrecord-Clone 2.01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling
cdrecord: Warning: Running on Linux-2.6.10
cdrecord: There are unsettled issues with Linux-2.5 and newer.
cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
scsidev: 'ATA'
devname: 'ATA'
scsibus: -2 target: -2 lun: -2
Warning: Using badly designed ATAPI via /dev/hd* interface.
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.8'.
scsibus1:
1,0,0   100) 'MATSHITA' 'UJDA730 DVD/CDRW' '1.00' Removable CD-ROM
1,1,0   101) *
1,2,0   102) *
1,3,0   103) *
1,4,0   104) *
1,5,0   105) *
1,6,0   106) *
1,7,0   107) *

My drive is a Matshita UJDA730, it can read DVD. dev=1,0,0. If your kernel is 2.4.X, you have two ways to check your device, first:

# cdrecord -scanbus

second,

# cdrdao scanbus

How to make an image iso

Command mkisofs will allow us to make an image iso of a directory. The following image iso will be named image.iso, you can call it foo.iso or save.iso, and path_of_your_directory is the absolute path of your directory, for example /home/user/project

# mkisofs -v -r -J -o image.iso path_of_your_directory

you can also do it for a file

# mkisofs -v -r -J -o image.iso path_of_your_file

Some explanations about the options used:
- -v is the verbose mode
- -r to reset the rights
- -J is the Joliet extension, it allows to support Long names of files
- -o is the output, here it is image.iso

Burning

The idea is to make an image iso with mkisofs and next to burn this image in our CD. Once iso have been created, we use cdrecord:

# cdrecord -v -speed=10 dev=ATA:1,0,0 -data image.iso

Fast Burning

Burn a CD could be faster without making ISO. We can do it through /dev/null. First, we have to find the size of ISO like follows:

# mkisofs -r -print-size path_of_your_directory

If you want to burn a file:

# mkisofs -r -print-size path_of_your_file

We obtain an integer, it is the image size, look at this example

Total extents scheduled to be written = 30147
30147

Now, the idea is to use a pipe on cdrecrord with the device. We are going to burn cd without making an image iso, just by using the image size (here 30147):

# mkisofs -r -print-size chemin_du_repertoire 2>/dev/null | cdrecord -v  -speed=10 -dev=ATA:1,0,0 tsize=30147s -

for a file, if the size is 65432:

# mkisofs -r -print-size chemin_du_repertoire 2>/dev/null | cdrecord -v  -speed=10 -dev=ATA:1,0,0 tsize=65432s -

Erase a CD-RW

You can find here the fast method:

cdrecord -v  -speed=10 -dev=ATA:1,0,0 -blank=fast

and the complete on:

cdrecord -v  -speed=10 -dev=ATA:1,0,0 -blank=all

Thanks to math-linux.com for this great tutorial!

3Feb/090

Linux-ready XScale net board ships

Gateworks Corp. is shipping the second of its power-sipping Cambria Network Platform boards. The Cambria GW2350 ships with an OpenWrt Linux-based board support package (BSP) and optional dev kit, and targets enterprise and residential network applications, says the company.

The Cambria GW2350 is a lower cost ($211 in volume) version of the Cambria GW2358-4 board that was announced in August, and offers a single Type III Mini-PCI socket instead of the GW2358-4's four slots, says the company. The Cambria GW2350 is targeted at customer premise equipment that requires "a rugged, small form factor network processing engine," says the company.

The board incorporates an Intel IXP435 XScale processor clocked at 667MHz. The IXP435 integrates an XScale core with a pair of network processor engines (NPEs) -- programmable processing elements with their own instruction and data memory.

Except for the difference in price and the number of Mini-PCI slots, the GW2350 appears to be identical to the GW2358-4. It offers 128MB of DDRII-400 SDRAM and 32MB of flash, with a CompactFlash socket for expansion. The board also includes two Ethernet ports, two USB 2.0 host ports, a serial port, and a variety of other I/O. A GPS receiver and an additional serial port are optional. The GW2350 typically consumes only six Watts, and supports power-over-ethernet (PoE), says Gateworks.

The board is touted for its broad 8-48VDC input range and its reverse polarity and transient protection, which together are said to support applications ranging from automotive devices to solar and battery-powered wireless installations. The Mini-PCI slot can be used for 802.11ab/g, 802.11n, or WiMAX radios, says the company.

The GW2350 is preloaded with the open source Redboot boot loader, and OpenWrt, a community-supported Linux distribution. In addition, a hardware/software development kit is available as a separate option. The Cambria Dev Kit (pictured above, right) adds a USB JTAG flash programming interface, a passive PoE power supply/injector, a cable set, and a Linux development CD that includes the OpenWrt-based BSP.

Availability

The Cambria GW2350 is shipping now from stock, with prices starting at $211 in OEM quantities, says Gateworks. Customized versions are said to be available for volumes as low as 100 pieces. No new price was provided for the Cambria Dev Kit, but in August it was said to cost $410 per unit. More information may be found here.

For more information on the GW2350, including a detailed spec list, please see our coverage of the almost identical GW2358-4.

3Feb/091

Building an embedded Linux system emulator

One of the hallmarks of embedded system programming is working with specialized hardware. Unfortunately, embedded system developers do not always have the luxury to develop and test their code on the actual hardware they target. Often, the hardware is developed in tandem with the system software and therefore it it is not available for much of the embedded system software development cycle.

While one can develop and test much of our code on a PC running Linux, such a PC is a very different environment from the target board. More often then not, the target board is not even of the same architecture as the PC. A solution to this problem can be obtained by using an emulator - a software tool that executes software code of our target platform in a virtual machine that is running on our development host, and running our system software in it.

The following article describes how to build an embedded Linux system running inside an emulator which can be used to develop, test and debug target code even without access to target hardware.

The components

To build our emulator we will need the following components:

  • Hardware emulator (we'll use Qemu)
  • Minimal Linux root file system containing a C library and Busybox
  • The Linux kernel


Installing Qemu

Created by Fabrice Ballard, Qemu is an open source machine emulator supporting seven target architectures, including x86, MIPS, ARM, and PowerPC. As first step, we will download and install the emulator. Depending on the Linux distribution you use on your workstation, you might be able to use the native package management system of the distribution to do so.

For Debian, Ubuntu and derivatives:

$ sudo apt-get install qemu

For Fedora and derivatives (as root):

# yum install qemu

For other distributions lacking a Qemu package, or for those wishing to obtain the very latest package (note that the "i386" label refers to the host running the emulator, and not the target platform):

$ wget http://bellard.org/qemu/qemu-0.9.1-i386.tar.gz
$ cd /
$ sudo tar zxvf qemu-0.9.1-i386.tar.gz

Or, as root:

# tar zxvf qemu-0.9.1-i386.tar.gz

Alternatively, you can download the sources and build the emulator from scratch. This has the added advantage that you can later adapt the emulator to more accurately reflect your actual hardware:

$ wget http://bellard.org/qemu/qemu-0.9.1.tar.gz
$ tar zxvf qemu-0.9.1.tar.gz
$ cd qemu-0.9.1/
$ ./configure
$ make
$ sudo make install

Or, as root:

# make install

Kernel and file system images

The Qemu emulator we have just installed provides a virtual machine mimicking our target hardware. To actually get Linux running on this virtual machine, however, we will need to download an image of the Linux kernel and a suitable root file system image for our target architecture.

Luckily, the Qemu project provides test images for several architectures that can be used to get a fast start with Qemu as an embedded Linux system emulator. Go to the Qemu project download page and choose one of the Qemu test disk images suitable for your embedded platform and download it to your Linux host (in this example we use ARM):

$ wget http://bellard.org/qemu/arm-test-0.2.tar.gz

Now extract the image:

$ tar zxvf arm-test-0.2.tar.gz
$ cd arm-test

Booting Linux on the emulator

Start up Qemu with the following command line, adjusting the architecture name, kernel file name, and root file system image name according to your specific architecture (again, we use ARM in this example):

$ qemu-system-arm -kernel zImage.integrator \
   -initrd arm_root.img -tftp / -redir tcp:9999::9999

The above command line starts Qemu in system emulation mode, booting into the kernel image zImage.integrator while loading into the virtual machine RAM the arm_root.img file system, and instructing Qemu to make your entire host root file system available for access via TFTP from the emulated machine (more on this ahead).

You should now be seeing a window similar to the following in which the emulated LCD display of the board is shown in main screenshot.

You can log-in with the user "root" -- no password is required.

Transferring files to and from the host

The emulator and file system are set up to automatically configure a virtual Ethernet interface in the virtual machine with an internal IP. Through that virtual network interface, the emulator is set up to enable transferring of files to and from the host machine file system using the TFTP protocol.

For example, the following command will copy the file "/home/gby/hello_emu" from the host file system to the current directory inside the emulator:

$ tftp -g -r /home/gby/hello_emu -l hello_emu 10.0.2.2

The following command will copy the file "/root/test.log" from the emulator to the host file system directory "/home/gby/":

$ tftp -p -l/root/test.log -r /home/gby/test.log 10.0.2.2

In addition, you can use the "wget" comment to transfer files using the FTP and HTTP protocol to the emulator from any compatible server accessible in the network:

$ wget http://codefidence.com/some/file

Qemu supports numerous other way to interact with the host and it's environment, including bridged virtual network interfaces (as opposed to the default NAT used in the example above). Bridged virtual network interfaces enable:

  • Using NFS to communicate with the host
  • Remote debugging from the host
  • VLAN support
  • Exposing the host file system as a FAT file system
  • Mounting disk, flash, or CDROM images from the host file system
  • Using USB devices connected to the host

For more information on these advanced options, please refer to the Qemu user manual.

Debugging user applications

Using the GNU debugger GDBserver agent, we can debug applications running inside the emulator using the GDB debugger on the host. To do this, first use one of the methods outlined above to copy the "gdbserver" executable to the emulator. Note that you will need a gdbserver executable that was built to run on the target architecture (such as ARM, in the example above), and not on that of the host!

Also note that since the test images do not contain debugging symbols for the system libraries, you will only be able to debug statically compiled applications using them. This limitation can be removed by building your own kernel and file system image (see below for more information on this topic).

$ tftp -g -r /home/gby/src/gdb/gdb/gdbserver/gdberver \
   -l gdbserver 10.0.2.2

Next, assign the gdbserver binary execute permissions:

$ chmod u+x gdbserver

Now, run the gdbserver agent, instructing it to use port 9999 (which we previously redirected to the emulator, when we launched qemu-system-arm from the command-line) to listen for connections from the debugger:

$ gdbserver 0.0.0.0:9999 /bin/myprog

Or, if you wish to attach to an already running program, use:

$ gdbserver 0.0.0.0:9999 --attach 1234

Finally, run the GDB debugger on your host and instruct it to connect to the host local port 9999:

$ arm-linux-gdb target/bin/myprog
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
...
(gdb) set solib-absulote-prefix /dev/null
(gdb) set solib-search-path target/lib/
(gdb) target remote 127.0.0.1:9999

Debugging the kernel

Using the Qemu emulator to debug kernel code is quite straight forward, as Qemu incorporates a minimal GDB agent as part of the emulator itself. To debug the Linux kernel running inside the emulator, add the "-s" parameter to the command line used to start Qemu:

$ qemu-system-arm -kernel zImage.integrator \
    -initrd arm_root.img -tftp / -redir tcp:9999::9999 -s

Now when the emulator starts, it will wait for a debugger connection on the default port "1234" (or a different port specific with the "-p" option), before proceeding with the boot. Once the emulator has started, you can debug the Linux kernel running inside it, using GDB on the host:

$ arm-linux-gdb linux/vmlinux
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
...
(gdb) target remote 127.0.0.1:1234

You can use GDB as you normally would. For example, type "cont" to launch the kernel:

(gdb) cont

Building your own kernel and file system images

So far we have seen how to use the Qemu emulator with the test kernel and file system images that are available on the Qemu site. To make full use of the emulator, we can create our own custom kernel and file system images that will better reflect the real target we are trying to develop for.

First, query Qemu regarding which boards it can emulate for your chosen architecture. Replace "arm" in the example above with one of: mips, x86_64, ppc, or sparc. For i386, simply use "qemu" as the command:

$ qemu-system-arm -M \?

Choose the board that most closely resembles your real target environment. Note that you can add support to Qemu of your specific true board. This requires some programming though, and we shall not cover it in this tutorial.

The creation of a kernel and file system for our emulated target is no different then doing the same task for real hardware. In fact, many tools are freely available to accomplish this task. In this example, we shall use the Buildroot framework. Buildroot is a set of make files and patches that simplify the generation of a cross-compilation tool chain and root file system for your target Linux system, using the uClibc C library.

First, we shall download the latest Buildroot release from the project web site and extract it:

$ wget http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2
$ tar jxvf buildroot-snapshot.tar.bz2
$ cd buildroot/

Next, let's configure Buildroot for our chosen target board:

$ make menuconfig

You will be presented with a menu enabling you to pick your architecture, sub-architecture, specific board to build for. Other options include GCC and uClibc versions, and related details. For each menu choice in the configuration tool, you can find associated help information describing the purpose of the entry.

At minimum, the following configuration options needs to be set:

  • Target Architecture option -- choose your target architecture (e.g., arm.)
  • Target Architecture Variant option -- Chose a specific model of the architecture (e.g., arm926t).
  • Target options menu -- If the target board you wish to emulate (that is supported by Qemu) is listed, turn on support for that board (e.g., enable the "ARM Ltd. Device Support" menu, and inside it choose the "Integrator arm926" option).
  • Toolchain menu -- Turn on "Build gdb server for the Target" option, and if you would like to test C++ programs on the emulator, also the "C++ cross-compiler support" option.
  • Target filesystem options menu -- Enable the "cpio the root filesystem" option, and choose the "gzip" compression method. You may also request the file system image to be copied to a specified directory once it is generated.
  • Kernel menu -- Choose the "linux (Advanced configuration)" option, and pick one of the offered Linux kernel versions of the list offered. Also, select the "zImage" binary format. Here, you can also specify a directory to copy the generated kernel to.In addition, you will need to supply a proper Linux kernel configuration file. Note that you can extract the kernel configuration file used to generate the kernel supplied as part of the test images, by issuing the following command from inside the emulator:
    $ zcat /proc/config.gz > linux.config

    Alternatively, Linux provides specific kernel configuration for optimal use with Qemu for some architectures. Run the following command to inspect the default kernel configuration included in a specific Linux kernel version:

    $ make help

When you're done configuring Buildroot, exit the configuration utility (making sure to OK saving the changes) and type: "make". Buildroot will now download all required sources, and build your new kernel and file system image for you. You should now be able to run the emulator using the kernel and file system image you have just created. Use the file name and path of the zImage binary as a parameter to Qemu's "-kernel" option, and the file name and path of the file system image with Qemu's "-initrd" parameter, like so:

$ qemu-system-arm -kernel zImage \
    -initrd rootfs.arm.cpio.gz -tftp / -redir tcp:9999::9999 -s

As we have shown, the Qemu emulator provides a fairly simple way to develop, debug, and test Linux kernels, drivers, and applications for a variety of embedded architectures, even when no actual hardware is available. More information about the software used in this article can be found on the qemu, gdb, and Buildroot websites.

About the author -- Gilad Ben-Yossef is the co-founder and CTO of Codefidence Ltd, and has been helping OEMs make and use free and open source software in commercial products and services since 1998. He is also the co-author of the book "Building Embedded Linux Systems," 2nd Edition. In addition, he is co-founder of Hamakor, an NPO devoted to the promotion of FOSS in Israel, as well as a founding organizer of "August Penguin," an Israeli community FOSS conference.

Gilad is a member of the Israeli chapter of Mensa, the Israeli Information Technology Association and the Israeli chapter of the Internet Society. He holds a B.A. in Computer Science from Tel-Aviv Jaffa Academic College. When not trying to make FOSS software do something the authors never intended, Gilad likes to SCUBA dive, read science fiction, and spend time with his wife Limor and his and two adorable girls, Almog and Yael.