#yum localinstall –nogpgcheck -y https://dl.google.com/linux/direct/google-chrome-stable_current_i386.rpm

This The Basic $lspci output of my Samsung Laptop:

For Ethernet Controller :-

Actully Realtek Ethernet controller driver rtl8169 Driver is supported by fedora but here we need r8168 driver do just download the package r8168-8.029.00.tar.bz2

and then go to your Download directory and use commands
#cd r8168
#./autorun.sh
It will rmmod yr rtl8169 driver and then load newly build driver r8168
Now your ethernet Controller will work successfully

//For Wireless

Driver is supported by fedora for the Network Controller : Intel Device 0896(rev 34) but its firmware is missing . So we need to load that firmware in our system .

just download a file name -   iwlwifi-6000g2b-5.ucode

and now put these file in /lib/firmware/ directory . and reboot your system
#cp  iwlwifi-6000g2b-5.ucode /lib/firmware/

or
you can usr

#yum install iwl6000g2b-firmware.noarch
and then reboot your System

Thts All you need to do

The Beagle Board is a pocket-sized reference board containing a Texas Instruments OMAP3530 system-on-a-chip (SoC) processor (ARM Cortex A-8 core) running at up to 600MHz. (Find a link to more system specs in Resources later in this article.) Tiny reference boards are not themselves necessarily newsworthy—companies such as Gumstix have been providing similar boards for several years, including some based on the OMAP3530 processor. I picked the Beagle Board because it is an inexpensive platform for learning how Linux and small systems work. It is a reasonable alternative for hobbyists designing projects for themselves, academics creating projects for classes, and professionals designing low-cost appliances or thin clients.

For More Board Information visit:

www.beagleboard.org/static/BBSRM_latest.pdf 

Required Items To Bring-up :

Three items are required to boot the Beagle Board:
1.A desktop or laptop computer with a serial port (see the sidebar Notes on host platforms for more information)
2.A serial connector
3.A USB device cable, standard-A to mini-A

The Beagle Board comes with no cables or connectors. See the Beagle Board Shopping List (in Resources) for a list of required and optional items, as well as links to them. Most of the items shown here are available individually or as a package.

Serial connection:

For the serial connection, you need the following components:
1.IDC10-to-DB9M serial cable
2.DB9F-to-DB9F null modem cable
3.DB9M-to-USB cable (optional if your host platform has an RS-232 port)
4.USB mini-B male-to-USB A male cable

The combination of the first three cables gives you a serial connection, which enables you to watch and interact with the board’s bootloader and operating system through a terminal emulation program on your host platform.

Input and output:

For input and output, you need the following items:
1. Powered USB 3-port hub with Ethernet
2. 5mm barrel power plug-to-USB A male adapter
3. USB mini-A-to-USB A female On-The-Go (OTG) cable (optional; lets it be powered over its USB connection)

These items give you the maximum benefit from using a Linux distribution on your Beagle Board. The built-in Ethernet gives you a network connection. The hub itself gives you a USB port for providing power to the Beagle Board with the 5mm power plug.

Keyboard, video, mouse :

For keyboard-video-mouse (KVM) functionality, you need the following items:
1. HDMI male-to-DVI-D male cable
2. Digital monitor
3. USB keyboard
4. USB mouse

You may be tempted to use a PS/2 keyboard with a converter. Take my advice: buy a USB keyboard. A PS/2 keyboard would probably work with the Ångström Linux distribution, the demo described in this article, but you may well go further than this in the future, and not all distributions include a PS/2 driver.

You may also be tempted to try to use an analog (VGA) monitor or a DVI-D-to-VGA conversion cable. The Beagle Board does not emit the analog signal that would drive this setup, so using a converter or analog monitor would be fruitless. If your monitor does not accept digital (HDMI or DVI-D) input, consider using a TV and a 4-pin S-video cable, instead. Also note that audio does not work acceptably yet on Ångström, so don’t spend too much time trying to track down speakers or headphones.

SD cards :

You need at least one SD card to store Linux and its bootloaders. If you do not want to go through the process of downloading the software and partitioning the card, Special Computing (see Resources for a link) has a deal: You can order a 4GB SD card with the Ångström demo preloaded.

Connecting the components :

When you have all of the parts, it’s time to start plugging things in. First, connect the serial port by performing the following steps:
1. Plug the IDC10 cable into the Beagle Board with the cable’s pin 1 going to pin 1 of the connector (the pink wire on the ribbon cable faces the outer corner of the board).
2. Plug the DB9M end into the null-modem DB9F/DB9F cable.
3. Plug the DB9F/DB9F cable into your host platform, if it has a DB9 port. Otherwise, plug the cable into a DB9M/USB cable, then plug that into the host.

Next, connect USB and power:
1. Plug the USB mini-A end of the mini-A/USB A female cable into the Beagle Board’s USB mini-A connector.
2. Plug the powered USB hub into the USB A female end of the same cable.
3. Plug the USB end of the USB/5mm barrel cable into the hub.
4. Plug the 5mm barrel end into the Beagle Board’s barrel connector.

Note: Do not connect power to the hub yet.

Now, connect the keyboard, mouse, and video:
1. Plug the HDMI end of video cable into the Beagle Board’s HDMI connector.
2. Plug the DVI-D end into your monitor.
3. Plug the USB keyboard into the hub.
4. Plug the USB mouse into the hub.

Setting up the operating system:

The host system is ready and the Beagle Board is set up. All you need now is an operating system.

Downloadable binaries exist for many Linux distributions that run on the Beagle Board, with Ångström, Maemo, Ubuntu, and Android being the most popular. All are under active development, and all have been demonstrated in public by professionals and hobbyists alike. This article covers the Ångström distribution, which is well tested and lean enough that it turns the Beagle Board into a viable Linux desktop machine and not-so-thin client. See Resources for links to video demonstrations as well as to the Ångström binary download.

The Ångström Linux distribution :

1. First-stage bootloader
2. Second-stage bootloader
3. Linux boot image (uImage)
4. Linux file system

The Beagle Board’s firmware contains a first-stage bootloader called X-loader. X-loader can also be loaded from a removable storage space (such as an SD card) in a signed file called MLO. X-loader bootstraps the system only enough to load the second-stage bootloader, which otherwise would not fit into memory.

The second-stage bootloader provided in flash memory on the Beagle Board is U-boot, although most distributions provide their own version of U-boot in a file called u-boot.bin. U-boot initializes the system, then boots the Linux kernel. It can also be run from the console.

The Linux boot image, named uImage, finally boots the Linux kernel, which resides in the Linux file system in the /boot directory.

There are several ways to set up the file system; the method shown here requires a bit of work at the beginning but is flexible. Also note that this is the way the pre-built Ångström SD cards arrive if you order them from Special Computing.

How Linux Boot (For Intel x86 Architecture) :

Stage 1 Boot Loader : 

The primary boot loader that resides in the MBR is a 512-byte image containing both program code and a small partition table (see Figure 2). The first 446 bytes are the primary boot loader, which contains both executable code and error message text. The next sixty-four bytes are the partition table, which contains a record for each of four partitions (sixteen bytes each). The MBR ends with two bytes that are defined as the magic number (0xAA55). The magic number serves as a validation check of the MBR.

The job of the primary boot loader is to find and load the secondary boot loader (stage 2). It does this by looking through the partition table for an active partition. When it finds an active partition, it scans the remaining partitions in the table to ensure that they’re all inactive. When this is verified, the active partition’s boot record is read from the device into RAM and executed.

Stage 2 Bootloader :

The secondary, or second-stage, boot loader could be more aptly called the kernel loader. The task at this stage is to load the Linux kernel and optional initial RAM disk.

The first- and second-stage boot loaders combined are called Linux Loader (LILO) or GRand Unified Bootloader (GRUB) in the x86 PC environment. Because LILO has some disadvantages that were corrected in GRUB, let’s look into GRUB.

The great thing about GRUB is that it includes knowledge of Linux file systems. Instead of using raw sectors on the disk, as LILO does, GRUB can load a Linux kernel from an ext2 or ext3 file system. It does this by making the two-stage boot loader into a three-stage boot loader. Stage 1 (MBR) boots a stage 1.5 boot loader that understands the particular file system containing the Linux kernel image. Examples include reiserfs_stage1_5 (to load from a Reiser journaling file system) or e2fs_stage1_5 (to load from an ext2 or ext3 file system). When the stage 1.5 boot loader is loaded and running, the stage 2 boot loader can be loaded.

With stage 2 loaded, GRUB can, upon request, display a list of available kernels (defined in /etc/grub.conf, with soft links from /etc/grub/menu.lst and /etc/grub.conf). You can select a kernel and even amend it with additional kernel parameters. Optionally, you can use a command-line shell for greater manual control over the boot process.

With the second-stage boot loader in memory, the file system is consulted, and the default kernel image and initrd image are loaded into memory. With the images ready, the stage 2 boot loader invokes the kernel image.

Kernel Image : 

With the kernel image in memory and control given from the stage 2 boot loader, the kernel stage begins. The kernel image isn’t so much an executable kernel, but a compressed kernel image. Typically this is a zImage (compressed image, less than 512KB) or a bzImage (big compressed image, greater than 512KB), that has been previously compressed with zlib. At the head of this kernel image is a routine that does some minimal amount of hardware setup and then decompresses the kernel contained within the kernel image and places it into high memory. If an initial RAM disk image is present, this routine moves it into memory and notes it for later use. The routine then calls the kernel and the kernel boot begins.

When the bzImage (for an i386 image) is invoked, you begin at ./arch/i386/boot/head.S in the start assembly routine (see Figure 3 for the major flow). This routine does some basic hardware setup and invokes the startup_32 routine in ./arch/i386/boot/compressed/head.S. This routine sets up a basic environment (stack, etc.) and clears the Block Started by Symbol (BSS). The kernel is then decompressed through a call to a C function called decompress_kernel (located in ./arch/i386/boot/compressed/misc.c). When the kernel is decompressed into memory, it is called. This is yet another startup_32 function, but this function is in ./arch/i386/kernel/head.S.

In the new startup_32 function (also called the swapper or process 0), the page tables are initialized and memory paging is enabled. The type of CPU is detected along with any optional floating-point unit (FPU) and stored away for later use. The start_kernel function is then invoked (init/main.c), which takes you to the non-architecture specific Linux kernel. This is, in essence, the main function for the Linux kernel.

With the call to start_kernel, a long list of initialization functions are called to set up interrupts, perform further memory configuration, and load the initial RAM disk. In the end, a call is made to kernel_thread (in arch/i386/kernel/process.c) to start the init function, which is the first user-space process. Finally, the idle task is started and the scheduler can now take control (after the call to cpu_idle). With interrupts enabled, the pre-emptive scheduler periodically takes control to provide multitasking.

During the boot of the kernel, the initial-RAM disk (initrd) that was loaded into memory by the stage 2 boot loader is copied into RAM and mounted. This initrd serves as a temporary root file system in RAM and allows the kernel to fully boot without having to mount any physical disks. Since the necessary modules needed to interface with peripherals can be part of the initrd, the kernel can be very small, but still support a large number of possible hardware configurations. After the kernel is booted, the root file system is pivoted (via pivot_root) where the initrd root file system is unmounted and the real root file system is mounted.

The initrd function allows you to create a small Linux kernel with drivers compiled as loadable modules. These loadable modules give the kernel the means to access disks and the file systems on those disks, as well as drivers for other hardware assets. Because the root file system is a file system on a disk, the initrd function provides a means of bootstrapping to gain access to the disk and mount the real root file system. In an embedded target without a hard disk, the initrd can be the final root file system, or the final root file system can be mounted via the Network File System (NFS).

Root File System (Init Process):

After the kernel is booted and initialized, the kernel starts the first user-space application. This is the first program invoked that is compiled with the standard C library. Prior to this point in the process, no standard C applications have been executed.

In a desktop Linux system, the first application started is commonly /sbin/init. But it need not be. Rarely do embedded systems require the extensive initialization provided by init (as configured through /etc/inittab). In many cases, you can invoke a simple shell script that starts the necessary embedded applications.

Resources : 

http://www.ibm.com/developerworks/linux/library/l-beagle-board/

http://www.ibm.com/developerworks/linux/library/l-linuxboot/

Systems

There are two types of system

1. General Purpose Systems
These systems refer to the computers which we are using in the houses and offices. General purpose systems act as a general platform for programming and performing certain other tasks.
General purpose systems prefer an operating system which may be UNIX, GNU/LINUX or Windows.
Here are some of the advantages of LINUX over other Operating System:
• Free of cost (usually called open source).
• Supports multi-user (First operating system to support multi user. In olden days one server carried an OS while other shares the same processor in the server).
• Flexible for programming.
• Better Security (It has the best security than any other operating system).
General purpose systems can perform any task but in small applications there
Is no need for bigger OS and hardware system. To overcome this concept Embedded System came, which is explained in the following section.
2 . Embedded Systems
Embedded Systems are different from that of the general purpose system. This system is generally of resources constrained. The resources refer to the hardware components.
Embedded Systems may or may not require an RTOS, whereas general purpose systems always do need an OS.

Difference between RTOS and OS
In general we hear the term OS which is nothing but the Operating System. Most of us are familiar in using the Operating Systems such as Windows 98, Windows XP etc. There is a new term used in the Embedded Systems named RTOS which is a Real Time OS.

Embedded OS
Operating systems are widely used in general purpose systems which may be LINUX or Windows. All operating systems uses an important concept called Time Sharing.
Time Sharing is nothing but performing many operations at a time, this has been take care by the OS.
The concept of time sharing can be best understood from the following figure.

The concept of DMA also comes into the picture in time sharing. In general purpose systems the tasks are allocated at different time slots. The user does not have any idea when the task will be completed.

Embedded RTOS
The RTOS are similar to the operating system but has smaller kernel (core of the operating system) size. It also uses the time sharing concept.
In general purpose the allocation of time can be adjusted by the OS, but in RTOS the time cannot be adjusted.

Processors
The General purpose systems use x86 processor.
Embedded Systems use controllers or processors such as ARM, FPGA etc.

Compiling and Cross Compiling
The RTOS cannot be used as such like an operating system. It has to be cross compiled for the particular processor. Other packages such as BIOS programming, Boot loader and Root file system also has to be used in Embedded linux environment.

BIOS
Basic Input Output System is the firmware that initializes the system. BIOS Programming has to be written and stored in to the flash memory.

Boot loader
An important package which is responsible for the kernel on the memory.
In General Purpose System Linux uses GRUB boot loader whereas the Embedded Linux system uses the U-boot bootloader.

Linux kernel
Lot of Linux kernel versions are available which can be cross-compiled for particular processor.

Root file system
Root file system contains all the binaries of the operating system.

Steps to make an Embedded Linux System to boot up
Hardwares used
Processor – s3c2440
Nor flash
Nand flash
SDRAM
Software packages
Linux kernel 2.6.29
u-boot bootloader
busy box

Compilation steps for linux kernel
Step 1:
tar –xvvzf arm-linux-gcc.tar.gz
unpacking the gcc compiler.
Step 2:
Export PATH=$PATH:~/usr/local/arm/4.3.2/bin
The tool chain for compiler is set
Step 3:
Tar –xvzf linux-2.6.29.tar.gz.
Unpacking the kernel
Step 4:
Make ARCH=arm CROSS_COMPILE=~/usr/local/arm/4.3.2/bin/
Step 5:
Make ARCH=arm CROSS_COMPILE=~/usr/local/arm/4.3.2/bin/ uImage

#include
#include
#include
#include
#include
#include

#ifndef DEBUG
#define DEBUG
#endif

MODULE_LICENSE(“GPL”);
MODULE_AUTHOR(“VAIBHAV”);
MODULE_DESCRIPTION(“Simple Modules init and exit”);

static short int data=4;
static int i=2;
static long int j=1;
static char *si=” vaibhav “;

static int pvtdata __initdata=1234;

static int __init vaibhav(void)
{
#ifdef DEBUG
printk(KERN_INFO “Begin !%s \n”,__func__);
#endif
#ifdef DEBUG
printk(KERN_ALERT “hello kernel !\n”);
#endif
#ifdef DEBUG
printk(KERN_ALERT “data=%d \t i=%d \t j=%ld\t si=%s\t pvtdata=%d\n”,data,i,j,si,pvtdata);
#endif
#ifdef DEBUG
printk(KERN_ALERT “The process is %s and its pid is %d \n”,current->comm,current->pid );
#endif
#ifdef DEBUG
printk(KERN_INFO “%s End\n”,__func__);
#endif
return 0;
}
module_init(vaibhav);
module_param(data,short,S_IRUGO);
module_param(i,int,S_IRUGO );
module_param(j,long,S_IRUGO);
module_param(si,charp,S_IRUGO);
module_param(pvtdata,int,S_IRUGO);

static void __exit vaibhav1(void)
{
#ifdef DEBUG
printk(KERN_INFO “Begin !%s \n”,__func__);
#endif
#ifdef DEBUG
printk(KERN_ALERT “Execution compleate \n”);
#endif
#ifdef DEBUG
printk(KERN_INFO “%s End \n”,__func__);
#endif
}

module_exit(vaibhav1);

when we authenticate the server request then server respond wth a three digit code to tell that your (client’s) last command was successfull then data line gets the control .Then file transfer in progress over the data connection. File transfer can be interrupted by sending a interrupt on the control line . The transfer rate of this protocol depends on the freq.,size of packts (transferring), bandwidth and traffic on the network.