plz help me to over come this.

/bin/sh: line 3: cd: x86_64-unknown-linux-gnu/libstdc++-v3: No such file or directory
make[1]: *** [check-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/home/emblogic/TOOLCHAIN/build-tools/build-gcc’
make: *** [do-check] Error 2

After using –enable-languages=”c” during configuration libstdc++-v3 error resolved. Now the error is for libmudflap.
How to disable libmudflap???

/bin/sh: line 3: cd: x86_64-unknown-linux-gnu/libmudflap: No such file or directory
make[1]: *** [check-target-libmudflap] Error 1
make[1]: Leaving directory `/home/emblogic/TOOLCHAIN/build-tools/build-gcc’
make: *** [do-check] Error 2

After using –disable-libmudflap, I got error below mentioned:

/bin/sh: line 3: cd: x86_64-unknown-linux-gnu/libssp: No such file or directory
make[1]: *** [check-target-libssp] Error 1
make[1]: Leaving directory `/home/emblogic/TOOLCHAIN/build-tools/build-gcc’
make: *** [do-check] Error 2

Used –disable-libssp

/bin/sh: line 3: cd: x86_64-unknown-linux-gnu/libgomp: No such file or directory
make[1]: *** [check-target-libgomp] Error 1
make[1]: Leaving directory `/home/emblogic/arm/TOOLCHAIN/build-tools/build-gcc’
make: *** [do-check] Error 2

Finally after disabling the flag libgomp. There is no error after make check. Compiled and installed gcc successfully…
Used –disable-libgomp
Snapshot:

PASS: test-expandargv-0.
PASS: test-expandargv-1.
PASS: test-expandargv-2.
PASS: test-expandargv-3.
PASS: test-expandargv-4.
PASS: test-expandargv-5.
PASS: test-expandargv-6.
make[3]: Leaving directory `/home/emblogic/arm/TOOLCHAIN/build-tools/build-gcc/libiberty/testsuite’
make[2]: Leaving directory `/home/emblogic/arm/TOOLCHAIN/build-tools/build-gcc/libiberty’
make[1]: Nothing to be done for `check-target’.
make[1]: Leaving directory `/home/emblogic/arm/TOOLCHAIN/build-tools/build-gcc’

RCS file: dec.h,v
Working file: dec.h
head: 1.1
branch:
locks: strict
emblogic: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
—————————-
revision 1.1 locked by: emblogic;
date: 2014/11/11 05:30:45; author: emblogic; state: Exp;
Initial revision
=============================================================================

RCS file: initialization.c,v
Working file: initialization.c
head: 1.2
branch:
locks: strict
emblogic: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 1
description:
implemented check_region(), release_region()
—————————-
revision 1.2 locked by: emblogic;
date: 2014/11/11 05:33:43; author: emblogic; state: Exp; lines: +2 -2
implemented request_region()
=============================================================================

RCS file: fileop.h,v
Working file: fileop.h
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 0
description:
=============================================================================

RCS file: dev_open.c,v
Working file: dev_open.c
head: 1.1
branch:
locks: strict
emblogic: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
—————————-
revision 1.1 locked by: emblogic;
date: 2014/11/11 05:32:50; author: emblogic; state: Exp;
Initial revision
=============================================================================

RCS file: dev_write.c,v
Working file: dev_write.c
head: 1.3
branch:
locks: strict
emblogic: 1.3
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 1
description:
—————————-
revision 1.3 locked by: emblogic;
date: 2014/11/11 05:40:03; author: emblogic; state: Exp; lines: +1 -0
first waited for the busy status then send the strobe.
to allow the reader to read the data.
=============================================================================

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.2
branch:
locks: strict
emblogic: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 1
description:
—————————-
revision 1.2 locked by: emblogic;
date: 2014/11/11 05:35:23; author: emblogic; state: Exp; lines: +2 -0
implemented release_region,
=============================================================================

RCS file: dev_read.c,v
Working file: dev_read.c
head: 1.2
branch:
locks: strict
emblogic: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 1
description:
following the protocols first send the busy to writer
—————————-
revision 1.2 locked by: emblogic;
date: 2014/11/11 05:57:34; author: emblogic; state: Exp; lines: +2 -2
after receiving the strobe from the writter, accepted the data.
=============================================================================

GRUB is dynamically configurable. This means that the user can make changes during the boot time, which include altering existing boot entries, adding new, custom entries, selecting different kernels, or modifying initrd. GRUB also supports Logical Block Address mode. This means that if your computer has a fairly modern BIOS that can access more than 8GB (first 1024 cylinders) of hard disk space, GRUB will automatically be able to access all of it.

GRUB can be run from or be installed to any device (floppy disk, hard disk, CD-ROM, USB drive, network drive) and can load operating systems from just as many locations, including network drives. It can also decompress operating system images before booting them.

A compiler is a program that turns source code into executable code. Like all programs, a compiler runs on a specific type of computer, and the new programs it outputs also run on a specific type of computer.[1]

The computer the compiler runs on is called the host, and the computer the new programs run on is called the target. When the host and target are the same type of machine, the compiler is a native compiler. When the host and target are different, the compiler is a cross compiler.[2]
Why cross-compile?

In theory, a PC user who wanted to build programs for some device could get the appropriate target hardware (or emulator), boot a Linux distro on that, and compile natively within that environment. While this is a valid approach (and possibly even a good idea when dealing with something like a Mac Mini), it has a few prominent downsides for things like a linksys router or iPod:

Speed – Target platforms are usually much slower than hosts, by an order of magnitude or more. Most special-purpose embedded hardware is designed for low cost and low power consumption, not high performance. Modern emulators (like qemu) are actually faster than a lot of the real world hardware they emulate, by virtue of running on high-powered desktop hardware.[3]

Capability – Compiling is very resource-intensive. The target platform usually doesn’t have gigabytes of memory and hundreds of gigabytes of disk space the way a desktop does; it may not even have the resources to build “hello world”, let alone large and complicated packages.

Availability – Bringing Linux up on a hardware platform it’s never run on before requires a cross-compiler. Even on long-established platforms like Arm or Mips, finding an up-to-date full-featured prebuilt native environment for a given target can be hard. If the platform in question isn’t normally used as a development workstation, there may not be a recent prebuilt distro readily available for it, and if there is it’s probably out of date. If you have to build your own distro for the target before you can build on the target, you’re back to cross-compiling anyway.

Flexibility – A fully capable Linux distribution consists of hundreds of packages, but a cross-compile environment can depend on the host’s existing distro from most things. Cross compiling focuses on building the target packages to be deployed, not spending time getting build-only prerequisites working on the target system.

Convenience – The user interface of headless boxes tends to be a bit crampled. Diagnosing build breaks is frustrating enough as it is. Installing from CD onto a machine that hasn’t got a CD-ROM drive is a pain. Rebooting back and forth between your test environment and your development environment gets old fast, and it’s nice to be able to recover from accidentally lobotomizing your test system.

Why is cross-compiling hard?
Portable native compiling is hard.

Most programs are developed on x86 hardware, where they are compiled natively. This means cross-compiling runs into two types of problems: problems with the programs themselves and problems with the build system.

The first type of problem affects all non-x86 targets, both for native and for cross-builds. Most programs make assumptions about the type of machine they run on, which must match the platform in question or the program won’t work. Common assumptions include:

Word size – Copying a pointer into an int may lose data on a 64 bit platform, and determining the size of a malloc by multiplying by 4 instead of sizeof(long) isn’t good either. Subtle security flaws due to integer overflows are also possible, ala “if (x+y < size) memset(src+x,0,y);”, which results in a 4 gigabyte memset on 32-bit hardware when x=1000 and y=0xFFFFFFF0…

Endianness – Different systems store binary data iternally in different ways, which means that block-reading int or float data from disk or the network may need translation. Type “man byteorder” for details.

Alignment – Some platforms (such as arm) can only read or write ints from addresses that are an even multiple of 4 bytes, otherwise they segfault. Even the ones that can handle arbitrary alignments are slower dealing with unaligned data (they have to fetch twice to get both halves), so the compiler will often pad structures to align variables. Treating structures as a lump of data that can be sent to disk or across the network thus requires extra work to ensure a consistent representation.

Default signedness – Whether the “char” data type defaults to signed or unsigned varies from platform to platform (and in some cases from compiler to compiler), which can cause some really surprising bugs. The easy workaround for this is to provide a compiler argument like “-funsigned-char” to force the default to a known value.

NOMMU – If your target platform doesn’t have a memory management unit, several things need to change. You need vfork() instead of fork(), only certain types of mmap() work (shared or read only, but not copy on write), and the stack doesn’t grow dynamically.

Most packages aim to be portable when compiled natively, and will at least accept patches to fix any of the above problems (with the possible exception of NOMMU issues) submitted to the appropriate development mailing list.

The most influential Unix shells have been the Bourne shell and the C shell, These shells have both been used as the coding base and model for many derivative and work-alike shells with extended feature sets.

The Bourne shell, sh, was written by Stephen Bourne at AT&T as the original Unix command line interpreter; it introduced the basic features common to all the Unix shells, including piping, here documents, command substitution, variables, control structures for condition-testing and looping and filename wildcarding. The language, including the use of a reversed keyword to mark the end of a block, was influenced by ALGOL 68.^[1]

The C shell, csh, was written by Bill Joy while a graduate student at University of California, Berkeley. The language, including the control structures and the expression grammar, was modeled on C. The C shell also introduced a large number of features for interactive work, including the history and editing mechanisms, aliases, directory stacks, tilde notation, cdpath, job control and path hashing.

Bash is a command processor, typically run in a text window, allowing the user to type commands which cause actions. Bash can also read commands from a file, called a script. Like all Unix shells, it supports filename wildcarding, piping, here documents, command substitution, variables and control structures for condition-testing and iteration.^[6] The keywords, syntax and other basic features of the language were all copied from sh. Other features, e.g., history, were copied from csh and ksh. Bash is a POSIX shell but with a number of extensions.

The name itself is an acronym, a pun, and a description. As an acronym, it stands for Bourne-again shell, referring to its objective as a free replacement for the Bourne shell.^[7] As a pun, it expressed that objective in a phrase that sounds similar to born again, a term for spiritual rebirth.^[8][9] The name is also descriptive of what it did, bashing together the features of sh, csh and ksh.

Specification of Raspberry Pi (Model B)
Target price         : US$ 35
SoC                    : Broadcom BCM2835 (CPU, GPU, DSP, SDRAM, and single USB port)
CPU                    : 700 MHz ARM1176JZF-S core (ARM11 family, ARMv6 instruction set)
GPU                   : Broadcom VideoCore IV @ 250 MHz

OpenGL ES 2.0 (24 GFLOPS)

MPEG-2 and VC-1 (with license), 1080p30 h.264/MPEG-4 AVC high profile decoder and encoder

Memory (SDRAM)    : 512 MB (shared with GPU) as of 15 October 2012
USB 2.0 ports            : 1 (direct from BCM2835 chip) 2 (via the built in integrated 3-port     USB hub)
Video input               : A CSI input connector allows for the connection of a RPF designed     camera module
Video outputs           : Composite RCA (PAL and NTSC), HDMI (rev 1.3 & 1.4), raw             LCD Panels via DSI

14 HDMI resolutions from 640×350 to 1920×1200 plus various                                               PAL and NTSC standards.

Audio outputs           : 3.5 mm jack, HDMI, and, as of revision 2 boards, I²S audio(also potentially for audio input)
Onboard storage       : SD / MMC / SDIO card slot (3.3 V card power support only)
Onboard network     : 10/100 Mbit/s Ethernet (8P8C) USB adapter on the third port of the USB hub
Low-level peripherals: 8 × GPIO, UART, I²C bus, SPI bus with two chip selects, I²S audio +3.3 V, +5 V, ground
Power ratings          : 700 mA (3.5 W)
Power source          : 5 V via MicroUSB or GPIO header
Size                        : 85.60 mm × 56 mm (3.370 in × 2.205 in)
Weight                     : 45 g (1.6 oz)
Operating systems   : Arch Linux ARM, Debian GNU/Linux, Gentoo, Fedora, FreeBSD, NetBSD, Plan 9, Raspbian OS, RISC OS, Slackware Linux, OR your own compiled OS (Toolchain in project 9)

Source

http://en.wikipedia.org/wiki/Raspberry_Pi

www.raspberrypi.org

2.BULIDDIR:- It is in this directory that will compile all source packages e.g.
export BUILDDIR=/root/chaine/build
3.TARGETMACH:-
This variable specifies the type of target architecture
e.g.
export TARGETMACH=arm-none-linux-gnueabi
4.BUILDMACH:-
This variable specifies the type of architecture in which the package is compiled.

export BUILDMACH=x86_64-pc-linux-gnu
5.INSTALLDIR
This variable provides information about the folder hosting the cross-toolchain.

export INSTALLDIR=/opt/arm

6.SYSROOTDIR :-
This variable provides information on the directory hosting the libraries and header files the kernel of the target system.e.g.
export SYSROOTDIR=/opt/arm/sysroot

7.CROSS:-
Indicates that we use the variable fields CROSS with arm-none-linux-gnueabi.
export CROSS=arm-none-linux-gnueabi

Formatted the SD card , booted it on the beagle board ….

I faced a problem :- Kernel panic: not syncing: no init found: Try passing init option….

Now finally overcame it and my card has successfully booted on the beagle board…