forked from luck/tmp_suning_uos_patched
1394f03221
This adds support for the Analog Devices Blackfin processor architecture, and currently supports the BF533, BF532, BF531, BF537, BF536, BF534, and BF561 (Dual Core) devices, with a variety of development platforms including those avaliable from Analog Devices (BF533-EZKit, BF533-STAMP, BF537-STAMP, BF561-EZKIT), and Bluetechnix! Tinyboards. The Blackfin architecture was jointly developed by Intel and Analog Devices Inc. (ADI) as the Micro Signal Architecture (MSA) core and introduced it in December of 2000. Since then ADI has put this core into its Blackfin processor family of devices. The Blackfin core has the advantages of a clean, orthogonal,RISC-like microprocessor instruction set. It combines a dual-MAC (Multiply/Accumulate), state-of-the-art signal processing engine and single-instruction, multiple-data (SIMD) multimedia capabilities into a single instruction-set architecture. The Blackfin architecture, including the instruction set, is described by the ADSP-BF53x/BF56x Blackfin Processor Programming Reference http://blackfin.uclinux.org/gf/download/frsrelease/29/2549/Blackfin_PRM.pdf The Blackfin processor is already supported by major releases of gcc, and there are binary and source rpms/tarballs for many architectures at: http://blackfin.uclinux.org/gf/project/toolchain/frs There is complete documentation, including "getting started" guides available at: http://docs.blackfin.uclinux.org/ which provides links to the sources and patches you will need in order to set up a cross-compiling environment for bfin-linux-uclibc This patch, as well as the other patches (toolchain, distribution, uClibc) are actively supported by Analog Devices Inc, at: http://blackfin.uclinux.org/ We have tested this on LTP, and our test plan (including pass/fails) can be found at: http://docs.blackfin.uclinux.org/doku.php?id=testing_the_linux_kernel [m.kozlowski@tuxland.pl: balance parenthesis in blackfin header files] Signed-off-by: Bryan Wu <bryan.wu@analog.com> Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Signed-off-by: Aubrey Li <aubrey.li@analog.com> Signed-off-by: Jie Zhang <jie.zhang@analog.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
135 lines
5.3 KiB
Plaintext
135 lines
5.3 KiB
Plaintext
config BINFMT_ELF
|
|
bool "Kernel support for ELF binaries"
|
|
depends on MMU && (BROKEN || !FRV)
|
|
default y
|
|
---help---
|
|
ELF (Executable and Linkable Format) is a format for libraries and
|
|
executables used across different architectures and operating
|
|
systems. Saying Y here will enable your kernel to run ELF binaries
|
|
and enlarge it by about 13 KB. ELF support under Linux has now all
|
|
but replaced the traditional Linux a.out formats (QMAGIC and ZMAGIC)
|
|
because it is portable (this does *not* mean that you will be able
|
|
to run executables from different architectures or operating systems
|
|
however) and makes building run-time libraries very easy. Many new
|
|
executables are distributed solely in ELF format. You definitely
|
|
want to say Y here.
|
|
|
|
Information about ELF is contained in the ELF HOWTO available from
|
|
<http://www.tldp.org/docs.html#howto>.
|
|
|
|
If you find that after upgrading from Linux kernel 1.2 and saying Y
|
|
here, you still can't run any ELF binaries (they just crash), then
|
|
you'll have to install the newest ELF runtime libraries, including
|
|
ld.so (check the file <file:Documentation/Changes> for location and
|
|
latest version).
|
|
|
|
config BINFMT_ELF_FDPIC
|
|
bool "Kernel support for FDPIC ELF binaries"
|
|
default y
|
|
depends on (FRV || BLACKFIN)
|
|
help
|
|
ELF FDPIC binaries are based on ELF, but allow the individual load
|
|
segments of a binary to be located in memory independently of each
|
|
other. This makes this format ideal for use in environments where no
|
|
MMU is available as it still permits text segments to be shared,
|
|
even if data segments are not.
|
|
|
|
It is also possible to run FDPIC ELF binaries on MMU linux also.
|
|
|
|
config BINFMT_FLAT
|
|
tristate "Kernel support for flat binaries"
|
|
depends on !MMU || SUPERH
|
|
help
|
|
Support uClinux FLAT format binaries.
|
|
|
|
config BINFMT_ZFLAT
|
|
bool "Enable ZFLAT support"
|
|
depends on BINFMT_FLAT
|
|
select ZLIB_INFLATE
|
|
help
|
|
Support FLAT format compressed binaries
|
|
|
|
config BINFMT_SHARED_FLAT
|
|
bool "Enable shared FLAT support"
|
|
depends on BINFMT_FLAT
|
|
help
|
|
Support FLAT shared libraries
|
|
|
|
config BINFMT_AOUT
|
|
tristate "Kernel support for a.out and ECOFF binaries"
|
|
depends on X86_32 || ALPHA || ARM || M68K || SPARC32
|
|
---help---
|
|
A.out (Assembler.OUTput) is a set of formats for libraries and
|
|
executables used in the earliest versions of UNIX. Linux used
|
|
the a.out formats QMAGIC and ZMAGIC until they were replaced
|
|
with the ELF format.
|
|
|
|
The conversion to ELF started in 1995. This option is primarily
|
|
provided for historical interest and for the benefit of those
|
|
who need to run binaries from that era.
|
|
|
|
Most people should answer N here. If you think you may have
|
|
occasional use for this format, enable module support above
|
|
and answer M here to compile this support as a module called
|
|
binfmt_aout.
|
|
|
|
If any crucial components of your system (such as /sbin/init
|
|
or /lib/ld.so) are still in a.out format, you will have to
|
|
say Y here.
|
|
|
|
config OSF4_COMPAT
|
|
bool "OSF/1 v4 readv/writev compatibility"
|
|
depends on ALPHA && BINFMT_AOUT
|
|
help
|
|
Say Y if you are using OSF/1 binaries (like Netscape and Acrobat)
|
|
with v4 shared libraries freely available from Compaq. If you're
|
|
going to use shared libraries from Tru64 version 5.0 or later, say N.
|
|
|
|
config BINFMT_EM86
|
|
tristate "Kernel support for Linux/Intel ELF binaries"
|
|
depends on ALPHA
|
|
---help---
|
|
Say Y here if you want to be able to execute Linux/Intel ELF
|
|
binaries just like native Alpha binaries on your Alpha machine. For
|
|
this to work, you need to have the emulator /usr/bin/em86 in place.
|
|
|
|
You can get the same functionality by saying N here and saying Y to
|
|
"Kernel support for MISC binaries".
|
|
|
|
You may answer M to compile the emulation support as a module and
|
|
later load the module when you want to use a Linux/Intel binary. The
|
|
module will be called binfmt_em86. If unsure, say Y.
|
|
|
|
config BINFMT_SOM
|
|
tristate "Kernel support for SOM binaries"
|
|
depends on PARISC && HPUX
|
|
help
|
|
SOM is a binary executable format inherited from HP/UX. Say
|
|
Y here to be able to load and execute SOM binaries directly.
|
|
|
|
config BINFMT_MISC
|
|
tristate "Kernel support for MISC binaries"
|
|
---help---
|
|
If you say Y here, it will be possible to plug wrapper-driven binary
|
|
formats into the kernel. You will like this especially when you use
|
|
programs that need an interpreter to run like Java, Python, .NET or
|
|
Emacs-Lisp. It's also useful if you often run DOS executables under
|
|
the Linux DOS emulator DOSEMU (read the DOSEMU-HOWTO, available from
|
|
<http://www.tldp.org/docs.html#howto>). Once you have
|
|
registered such a binary class with the kernel, you can start one of
|
|
those programs simply by typing in its name at a shell prompt; Linux
|
|
will automatically feed it to the correct interpreter.
|
|
|
|
You can do other nice things, too. Read the file
|
|
<file:Documentation/binfmt_misc.txt> to learn how to use this
|
|
feature, <file:Documentation/java.txt> for information about how
|
|
to include Java support. and <file:Documentation/mono.txt> for
|
|
information about how to include Mono-based .NET support.
|
|
|
|
To use binfmt_misc, you will need to mount it:
|
|
mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc
|
|
|
|
You may say M here for module support and later load the module when
|
|
you have use for it; the module is called binfmt_misc. If you
|
|
don't know what to answer at this point, say Y.
|