https://elinux.org/api.php?action=feedcontributions&user=Vapier&feedformat=atomeLinux.org - User contributions [en]2024-03-28T19:30:56ZUser contributionsMediaWiki 1.31.0https://elinux.org/index.php?title=Android_Build_System&diff=388096Android Build System2015-08-24T17:57:12Z<p>Vapier: /* Specifying what to build */ drop duplicate `source` step</p>
<hr />
<div>The Android Build system are described at:<br />
https://android.googlesource.com/platform/build/+/master/core/build-system.html<br />
<br />
You use build/envsetup.sh to set up a "convenience environment" for working on the<br />
Android source code. This file should be source'ed into your current shell environment.<br />
After doing so you can type 'help' (or 'hmm') for a list of defined functions which are helpful<br />
for interacting with the source.<br />
<br />
== Overview ==<br />
The build system uses some pre-set environment variables and a series of 'make' files<br />
in order to build an Android system and prepare it for deployment to a platform.<br />
<br />
Android make files end in the extension '.mk' by convention, with the ''main'' make file<br />
in any particular source directory being named 'Android.mk'.<br />
<br />
There is only one official file named 'Makefile', at the top of the source tree for the whole repository. You set some environment variables, then type 'make' to build stuff. You can add some options to the make command line (other targets) to turn on verbose output, or perform different actions.<br />
<br />
The build output is placed in 'out/host' and 'out/target' Stuff under 'out/host' are things<br />
compiled for your host platform (your desktop machine). Stuff under 'out/target/product/<platform-name>' eventually makes it's way to a target device (or emulator).<br />
<br />
The directory 'out/target/product/<platform-name>/obj' is used for staging "object" files, which<br />
are intermediate binary images used for building the final programs. Stuff that actually lands in<br />
the file system of the target is stored in the directories root, system, and data, under<br />
'out/target/product/<platform-name>'. Usually, these are bundled up into image files called<br />
system.img, ramdisk.img, and userdata.img.<br />
<br />
This matches the separate file system partitions used on most Android devices.<br />
<br />
== Some Details ==<br />
=== What tools are used ===<br />
During the build you will be using 'make' to control the build steps themselves. A host<br />
toolchain (compiler, linker and other tools) and libraries will be used to build programs<br />
and tools that will run on the host. A different toolchain is used to compile the C and<br />
C++ code that will wind up on the target (which is an embedded board, device or the emulator).<br />
This is usually a "cross" toolchain that runs on an X86 platform, but produces code for some other<br />
platform (most commonly ARM). The kernel is compiled as a standalone binary (it does not use<br />
a program loader or link to any outside libraries). Other items, like native programs (e.g. init or toolbox), daemons or libraries will link against bionic or other system libraries.<br />
<br />
You will be using a Java compiler and a bunch of java-related tools to build<br />
most of the application framework, system services and Android applications themselves.<br />
Finally, tools are used to package the applications and resource files, and to <br />
create the filesystem images that can be installed on a device or used with the simulator.<br />
<br />
=== Telling the system where the Java toolchain is ===<br />
Before you build anything, you have to tell the Android build system where your Java SDK<br />
is. (Installing a Java SDK is a pre-requisite for building).<br />
<br />
Do this by setting a JAVA_HOME environment variable.<br />
<br />
=== Specifying what to build ===<br />
In order to decide what to build, and how to build it, the build system requires that some<br />
variables be set. Different products, with different packages and options can<br />
be built from the same source tree. The variables to control this can be set via a file<br />
with declarations of 'make' variables, or can be specified in the environment.<br />
<br />
A device vendor can create definition files that describe what is to be included on<br />
a particular board or for a particular product. The definition file is called:<br />
buildspec.mk, and it is located in the top-level source directory. You can edit this<br />
manually to hardcode your selections.<br />
<br />
If you have a buildspec.mk file, it sets all the make variables needed for a build, and<br />
you don't have to mess with options.<br />
<br />
Another method of specifying options is to set environment variables. The build system<br />
has a rather ornate method of managing these options for you.<br />
<br />
To set up your build environment, you need to load the variables and functions in build/envsetup.sh.<br />
Do this by 'source-ing' the file into your shell environment, like this:<br />
$ . build/envsetup.sh<br />
<br />
You can type 'help' (or 'hmm') at this point to see some utility functions that are available to make<br />
it easier to work with the source.<br />
<br />
To select the set of things you want to build, and what items to build for, you use either the<br />
'choosecombo' function or the 'lunch' function. 'choosecombo' will walk you through the different<br />
items you have to select, one-by-one, while 'lunch' allows you select some pre-set combinations.<br />
<br />
The items that have to be defined for a build are:<br />
* the product ('generic' or some specific board or platform name)<br />
* the build variant ('user', 'userdebug', or 'eng')<br />
* whether you're running on a simulator ('true' or 'false')<br />
* the build type ('release' or 'debug')<br />
<br />
Descriptions of these different build variants are at http://source.android.com/porting/build_system.html#androidBuildVariants<br />
<br />
The build process from a user perspective is described pretty well in this blog post: [http://blog.codepainters.com/2009/12/18/first-android-platform-build/ First Android platform build] by CodePainters, December 2009<br />
<br />
=== Actually building the system ===<br />
Once you have things set up, you actually build the system with the 'make' command.<br />
<br />
To build the whole thing, run 'make' in the top directory. The build will take a long time, if<br />
you are building everything (for example, the first time you do it).<br />
<br />
== Build tricks ==<br />
=== Seeing the actual commands used to build the software ===<br />
Use the "showcommands" target on your 'make' line:<br />
$ make -j4 showcommands<br />
<br />
This can be used in conjunction with another make target, to see the commands for that build.<br />
That is, 'showcommands' is not a target itself, but just a modifier for the specified build.<br />
<br />
In the example above, the -j4 is unrelated to the showcommands option, and is used to<br />
execute 4 make sessions that run in parallel.<br />
<br />
=== Make targets ===<br />
Here is a list of different make targets you can use to build different parts of the system:<br />
<br />
* make sdk - build the tools that are part of an SDK (adb, fastboot, etc.)<br />
* make snod - build the system image from the current software binaries<br />
* make services<br />
* make runtime<br />
* make droid - make droid is the normal build.<br />
* make all - make everything, whether it is included in the product definition or not<br />
* make clean - remove all built files (prepare for a new build). Same as rm -rf out/<configuration>/<br />
* make modules - shows a list of submodules that can be built (List of all LOCAL_MODULE definitions)<br />
* make <local_module> - make a specific module (note that this is not the same as directory name. It is the LOCAL_MODULE definition in the Android.mk file)<br />
* make clean-<local_module> - clean a specific module<br />
* make bootimage TARGET_PREBUILT_KERNEL=/path/to/bzImage - create a new boot image with custom bzImage<br />
<br />
=== Helper macros and functions ===<br />
There are some helper macros and functions that are installed when you source envsetup.sh. They are documented<br />
at the top of envesetup.sh, but here is information about a few of them:<br />
<br />
* croot - change directory to the top of the tree<br />
* m - execute 'make' from the top of the tree (even if your current directory is somewhere else)<br />
* mm - builds all of the modules in the current directory<br />
* mmm <dir1> ... - build all of the modules in the supplied directories<br />
* cgrep <pattern> - grep on all local C/C++ files<br />
* jgrep <pattern> - grep on all local Java files<br />
* resgrep <pattern> - grep on all local res/*.xml files<br />
* godir <filename> - go to the directory containing a file<br />
<br />
=== Speeding up the build ===<br />
You can use the '-j' option with make, to start multiple threads of make execution concurrently.<br />
<br />
In my experience, you should specify about 2 more threads than you have processors on your machine.<br />
If you have 2 processors, use 'make -j4', If they are hyperthreaded (meaning you have 4 virtual<br />
processors), try 'make -j6.<br />
<br />
You can also specify to use the 'ccache' compiler cache, which will speed up things once you have<br />
built things a first time. To do this, specify 'export USE_CCACHE=1' at your shell command line.<br />
(Note that ccache is included in the prebuilt section of the repository, and does not have to be<br />
installed on your host separately.)<br />
<br />
=== Building only an individual program or module ===<br />
If you use build/envsetup.sh, you can use some of the defined functions to build<br />
only a part of the tree. Use the 'mm' or 'mmm' commands to do this.<br />
<br />
The 'mm' command makes stuff in the current directory (and sub-directories, I believe).<br />
With the 'mmm' command, you specify a directory or list of directories, and it builds those.<br />
<br />
To install your changes, do 'make snod' from the top of tree.<br />
'make snod' builds a new system image from current binaries.<br />
<br />
=== Setting module-specific build parameters ===<br />
Some code in Android system can be customized in the way they are built (separate from the build<br />
variant and release vs. debug options). You can set variables that control individual<br />
build options, either by setting them in the environment or by passing them directly to<br />
'make' (or the 'm...' functions which call 'make'.)<br />
<br />
For example, the 'init' program can be built with support for bootchart logging<br />
by setting the INIT_BOOTCHART variable. (See [[Using Bootchart on Android]] for why<br />
you might want to do this.)<br />
<br />
You can accomplish either with:<br />
$ touch system/init/init.c<br />
$ export INIT_BOOTCHART=true<br />
$ make<br />
or<br />
$ touch system/init/init.c<br />
$ m INIT_BOOTCHART=true<br />
<br />
== Makefile tricks ==<br />
These are some tips for things you can use in your own Android.mk files.<br />
<br />
=== build helper functions ===<br />
A whole bunch of build helper functions are defined in the file build/core/definitions.mk<br />
<br />
Try grep define build/core/definitions.mk for an exhaustive list.<br />
<br />
Here are some possibly interesting functions:<br />
* print-vars - shall all Makefile variables, for debugging<br />
* emit-line - output a line during building, to a file<br />
* dump-words-to-file - output a list of words to a file<br />
* copy-one-file - copy a file from one place to another (dest on target?)<br />
<br />
<br />
=== Add a file directly to the output area ===<br />
You can copy a file directly to the output area, without building anything,<br />
using the add-prebuilt-files function.<br />
<br />
The following line, extracted from prebuilt/android-arm/gdbserver/Android.mk<br />
copies a list of files to the EXECUTABLES directory in the output area:<br />
<br />
$(call add-prebuilt-files, EXECUTABLES, $(prebuilt_files))<br />
<br />
== Adding a new program to build ==<br />
=== Steps for adding a new program to the Android source tree ===<br />
* make a directory under 'external'<br />
** e.g. ANDROID/external/myprogram<br />
* create your C/cpp files.<br />
* create Android.mk as clone of external/ping/Android.mk<br />
* Change the names ping.c and ping to match your C/cpp files and program name<br />
* add the directory name in ANDROID/build/core/main.mk after external/zlib as external/myprogram<br />
* make from the root of the source tree<br />
* your files will show up in the build output area, and in system images.<br />
** You can copy your file from the build output area, under out/target/product/..., if you want to copy it individually to the target (not do a whole install)<br />
<br />
See http://www.aton.com/android-native-development-using-the-android-open-source-project/ for a lot more detail.<br />
<br />
== Building the kernel ==<br />
The kernel is "outside" of the normal Android build system (indeed, the kernel is not included by default in the Android Open Source Project). However, there are tools in AOSP for building a kernel.<br />
If you are building the kernel, start on this page: http://source.android.com/source/building-kernels.html<br />
<br />
If you are building the kernel for the emulator, you may also want to look at:<br />
http://stackoverflow.com/questions/1809774/android-kernel-compile-and-test-with-android-emulator<br />
<br />
And, Ron M wrote (on the android-kernel mailing list, on May 21, 2012):<br />
<br />
This post is very old - but nothing has changes as far as AOSP is concerned, so <br />
in case anyone is interested and runs into this problem when building for QEMU:<br />
<br />
There is actually a nice and shorter way to build the kernel for your QEMU <br />
target provided by the AOSP:<br />
<br />
1. cd to your kernel source dir (Only goldfish 2.6.29 works out of the box for the emulator)<br />
<br />
2. ${ANDROID_BUILD_TOP}/external/qemu/distrib/build-kernel.sh -j=64 --arch=x86 --out=$YourOutDir<br />
<br />
3. emulator -kernel ${YourOutDir}/kernel-qemu # run emulator:<br />
<br />
<br />
Step #2 calls the toolbox.sh wrapper scripts which works around the SSE <br />
disabling gcc warning - which happens for GCC < 4.5 (as in the AOSP prebuilt X86 <br />
toolchain).<br />
<br />
This script adds the " -mfpmath=387 -fno-pic" in case it is an X86 and that in <br />
turn eliminates the compilation errors seen above.<br />
<br />
To have finer control over the build process, you can use the "toolbox.sh" <br />
wrapper and set some other stuff without modifying the script files.<br />
<br />
An example for building the same emulator is below:<br />
<br />
# Set arch<br />
export ARCH=x86<br />
# Have make refer to the QEMU wrapper script for building android over x86 <br />
(eliminates the errors listed above)<br />
export <br />
CROSS_COMPILE=${ANDROID_BUILD_TOP}/external/qemu/distrib/kernel-toolchain/android-kernel-toolchain-<br />
# Put your cross compiler here. I am using the AOSP prebuilt one in this example<br />
export <br />
REAL_CROSS_COMPILE=${ANDROID_BUILD_TOP}/prebuilt/linux-x86/toolchain/i686-android-linux-4.4.3/bin/i686-android-linux-<br />
# Configure your kernel - here I am taking the default goldfish_defconfig<br />
make goldfish_defconfig<br />
# build<br />
make -j64<br />
# Run emulator:<br />
emulator -kernel arch/x86/boot/bzImage -show-kernel<br />
<br />
<br />
This works for the 2.6.29 goldfish branch. If anyone is using the emulator with <br />
a 3+ kernel I would be like to hear about it.<br />
<br />
<br />
[[Category:Android]]</div>Vapierhttps://elinux.org/index.php?title=Android_Build_System&diff=388081Android Build System2015-08-24T17:44:25Z<p>Vapier: clean up dead links to build system docs</p>
<hr />
<div>The Android Build system are described at:<br />
https://android.googlesource.com/platform/build/+/master/core/build-system.html<br />
<br />
You use build/envsetup.sh to set up a "convenience environment" for working on the<br />
Android source code. This file should be source'ed into your current shell environment.<br />
After doing so you can type 'help' (or 'hmm') for a list of defined functions which are helpful<br />
for interacting with the source.<br />
<br />
== Overview ==<br />
The build system uses some pre-set environment variables and a series of 'make' files<br />
in order to build an Android system and prepare it for deployment to a platform.<br />
<br />
Android make files end in the extension '.mk' by convention, with the ''main'' make file<br />
in any particular source directory being named 'Android.mk'.<br />
<br />
There is only one official file named 'Makefile', at the top of the source tree for the whole repository. You set some environment variables, then type 'make' to build stuff. You can add some options to the make command line (other targets) to turn on verbose output, or perform different actions.<br />
<br />
The build output is placed in 'out/host' and 'out/target' Stuff under 'out/host' are things<br />
compiled for your host platform (your desktop machine). Stuff under 'out/target/product/<platform-name>' eventually makes it's way to a target device (or emulator).<br />
<br />
The directory 'out/target/product/<platform-name>/obj' is used for staging "object" files, which<br />
are intermediate binary images used for building the final programs. Stuff that actually lands in<br />
the file system of the target is stored in the directories root, system, and data, under<br />
'out/target/product/<platform-name>'. Usually, these are bundled up into image files called<br />
system.img, ramdisk.img, and userdata.img.<br />
<br />
This matches the separate file system partitions used on most Android devices.<br />
<br />
== Some Details ==<br />
=== What tools are used ===<br />
During the build you will be using 'make' to control the build steps themselves. A host<br />
toolchain (compiler, linker and other tools) and libraries will be used to build programs<br />
and tools that will run on the host. A different toolchain is used to compile the C and<br />
C++ code that will wind up on the target (which is an embedded board, device or the emulator).<br />
This is usually a "cross" toolchain that runs on an X86 platform, but produces code for some other<br />
platform (most commonly ARM). The kernel is compiled as a standalone binary (it does not use<br />
a program loader or link to any outside libraries). Other items, like native programs (e.g. init or toolbox), daemons or libraries will link against bionic or other system libraries.<br />
<br />
You will be using a Java compiler and a bunch of java-related tools to build<br />
most of the application framework, system services and Android applications themselves.<br />
Finally, tools are used to package the applications and resource files, and to <br />
create the filesystem images that can be installed on a device or used with the simulator.<br />
<br />
=== Telling the system where the Java toolchain is ===<br />
Before you build anything, you have to tell the Android build system where your Java SDK<br />
is. (Installing a Java SDK is a pre-requisite for building).<br />
<br />
Do this by setting a JAVA_HOME environment variable.<br />
<br />
=== Specifying what to build ===<br />
In order to decide what to build, and how to build it, the build system requires that some<br />
variables be set. Different products, with different packages and options can<br />
be built from the same source tree. The variables to control this can be set via a file<br />
with declarations of 'make' variables, or can be specified in the environment.<br />
<br />
A device vendor can create definition files that describe what is to be included on<br />
a particular board or for a particular product. The definition file is called:<br />
buildspec.mk, and it is located in the top-level source directory. You can edit this<br />
manually to hardcode your selections.<br />
<br />
If you have a buildspec.mk file, it sets all the make variables needed for a build, and<br />
you don't have to mess with options.<br />
<br />
Another method of specifying options is to set environment variables. The build system<br />
has a rather ornate method of managing these options for you.<br />
<br />
To set up your build environment, you need to load the variables and functions in build/envsetup.sh.<br />
Do this by 'source-ing' the file into your shell environment, like this:<br />
$ source build/envsetup.sh<br />
or<br />
$ . build/envsetup.sh<br />
<br />
You can type 'help' (or 'hmm') at this point to see some utility functions that are available to make<br />
it easier to work with the source.<br />
<br />
To select the set of things you want to build, and what items to build for, you use either the<br />
'choosecombo' function or the 'lunch' function. 'choosecombo' will walk you through the different<br />
items you have to select, one-by-one, while 'lunch' allows you select some pre-set combinations.<br />
<br />
The items that have to be defined for a build are:<br />
* the product ('generic' or some specific board or platform name)<br />
* the build variant ('user', 'userdebug', or 'eng')<br />
* whether you're running on a simulator ('true' or 'false')<br />
* the build type ('release' or 'debug')<br />
<br />
Descriptions of these different build variants are at http://source.android.com/porting/build_system.html#androidBuildVariants<br />
<br />
The build process from a user perspective is described pretty well in this blog post: [http://blog.codepainters.com/2009/12/18/first-android-platform-build/ First Android platform build] by CodePainters, December 2009<br />
<br />
=== Actually building the system ===<br />
Once you have things set up, you actually build the system with the 'make' command.<br />
<br />
To build the whole thing, run 'make' in the top directory. The build will take a long time, if<br />
you are building everything (for example, the first time you do it).<br />
<br />
== Build tricks ==<br />
=== Seeing the actual commands used to build the software ===<br />
Use the "showcommands" target on your 'make' line:<br />
$ make -j4 showcommands<br />
<br />
This can be used in conjunction with another make target, to see the commands for that build.<br />
That is, 'showcommands' is not a target itself, but just a modifier for the specified build.<br />
<br />
In the example above, the -j4 is unrelated to the showcommands option, and is used to<br />
execute 4 make sessions that run in parallel.<br />
<br />
=== Make targets ===<br />
Here is a list of different make targets you can use to build different parts of the system:<br />
<br />
* make sdk - build the tools that are part of an SDK (adb, fastboot, etc.)<br />
* make snod - build the system image from the current software binaries<br />
* make services<br />
* make runtime<br />
* make droid - make droid is the normal build.<br />
* make all - make everything, whether it is included in the product definition or not<br />
* make clean - remove all built files (prepare for a new build). Same as rm -rf out/<configuration>/<br />
* make modules - shows a list of submodules that can be built (List of all LOCAL_MODULE definitions)<br />
* make <local_module> - make a specific module (note that this is not the same as directory name. It is the LOCAL_MODULE definition in the Android.mk file)<br />
* make clean-<local_module> - clean a specific module<br />
* make bootimage TARGET_PREBUILT_KERNEL=/path/to/bzImage - create a new boot image with custom bzImage<br />
<br />
=== Helper macros and functions ===<br />
There are some helper macros and functions that are installed when you source envsetup.sh. They are documented<br />
at the top of envesetup.sh, but here is information about a few of them:<br />
<br />
* croot - change directory to the top of the tree<br />
* m - execute 'make' from the top of the tree (even if your current directory is somewhere else)<br />
* mm - builds all of the modules in the current directory<br />
* mmm <dir1> ... - build all of the modules in the supplied directories<br />
* cgrep <pattern> - grep on all local C/C++ files<br />
* jgrep <pattern> - grep on all local Java files<br />
* resgrep <pattern> - grep on all local res/*.xml files<br />
* godir <filename> - go to the directory containing a file<br />
<br />
=== Speeding up the build ===<br />
You can use the '-j' option with make, to start multiple threads of make execution concurrently.<br />
<br />
In my experience, you should specify about 2 more threads than you have processors on your machine.<br />
If you have 2 processors, use 'make -j4', If they are hyperthreaded (meaning you have 4 virtual<br />
processors), try 'make -j6.<br />
<br />
You can also specify to use the 'ccache' compiler cache, which will speed up things once you have<br />
built things a first time. To do this, specify 'export USE_CCACHE=1' at your shell command line.<br />
(Note that ccache is included in the prebuilt section of the repository, and does not have to be<br />
installed on your host separately.)<br />
<br />
=== Building only an individual program or module ===<br />
If you use build/envsetup.sh, you can use some of the defined functions to build<br />
only a part of the tree. Use the 'mm' or 'mmm' commands to do this.<br />
<br />
The 'mm' command makes stuff in the current directory (and sub-directories, I believe).<br />
With the 'mmm' command, you specify a directory or list of directories, and it builds those.<br />
<br />
To install your changes, do 'make snod' from the top of tree.<br />
'make snod' builds a new system image from current binaries.<br />
<br />
=== Setting module-specific build parameters ===<br />
Some code in Android system can be customized in the way they are built (separate from the build<br />
variant and release vs. debug options). You can set variables that control individual<br />
build options, either by setting them in the environment or by passing them directly to<br />
'make' (or the 'm...' functions which call 'make'.)<br />
<br />
For example, the 'init' program can be built with support for bootchart logging<br />
by setting the INIT_BOOTCHART variable. (See [[Using Bootchart on Android]] for why<br />
you might want to do this.)<br />
<br />
You can accomplish either with:<br />
$ touch system/init/init.c<br />
$ export INIT_BOOTCHART=true<br />
$ make<br />
or<br />
$ touch system/init/init.c<br />
$ m INIT_BOOTCHART=true<br />
<br />
== Makefile tricks ==<br />
These are some tips for things you can use in your own Android.mk files.<br />
<br />
=== build helper functions ===<br />
A whole bunch of build helper functions are defined in the file build/core/definitions.mk<br />
<br />
Try grep define build/core/definitions.mk for an exhaustive list.<br />
<br />
Here are some possibly interesting functions:<br />
* print-vars - shall all Makefile variables, for debugging<br />
* emit-line - output a line during building, to a file<br />
* dump-words-to-file - output a list of words to a file<br />
* copy-one-file - copy a file from one place to another (dest on target?)<br />
<br />
<br />
=== Add a file directly to the output area ===<br />
You can copy a file directly to the output area, without building anything,<br />
using the add-prebuilt-files function.<br />
<br />
The following line, extracted from prebuilt/android-arm/gdbserver/Android.mk<br />
copies a list of files to the EXECUTABLES directory in the output area:<br />
<br />
$(call add-prebuilt-files, EXECUTABLES, $(prebuilt_files))<br />
<br />
== Adding a new program to build ==<br />
=== Steps for adding a new program to the Android source tree ===<br />
* make a directory under 'external'<br />
** e.g. ANDROID/external/myprogram<br />
* create your C/cpp files.<br />
* create Android.mk as clone of external/ping/Android.mk<br />
* Change the names ping.c and ping to match your C/cpp files and program name<br />
* add the directory name in ANDROID/build/core/main.mk after external/zlib as external/myprogram<br />
* make from the root of the source tree<br />
* your files will show up in the build output area, and in system images.<br />
** You can copy your file from the build output area, under out/target/product/..., if you want to copy it individually to the target (not do a whole install)<br />
<br />
See http://www.aton.com/android-native-development-using-the-android-open-source-project/ for a lot more detail.<br />
<br />
== Building the kernel ==<br />
The kernel is "outside" of the normal Android build system (indeed, the kernel is not included by default in the Android Open Source Project). However, there are tools in AOSP for building a kernel.<br />
If you are building the kernel, start on this page: http://source.android.com/source/building-kernels.html<br />
<br />
If you are building the kernel for the emulator, you may also want to look at:<br />
http://stackoverflow.com/questions/1809774/android-kernel-compile-and-test-with-android-emulator<br />
<br />
And, Ron M wrote (on the android-kernel mailing list, on May 21, 2012):<br />
<br />
This post is very old - but nothing has changes as far as AOSP is concerned, so <br />
in case anyone is interested and runs into this problem when building for QEMU:<br />
<br />
There is actually a nice and shorter way to build the kernel for your QEMU <br />
target provided by the AOSP:<br />
<br />
1. cd to your kernel source dir (Only goldfish 2.6.29 works out of the box for the emulator)<br />
<br />
2. ${ANDROID_BUILD_TOP}/external/qemu/distrib/build-kernel.sh -j=64 --arch=x86 --out=$YourOutDir<br />
<br />
3. emulator -kernel ${YourOutDir}/kernel-qemu # run emulator:<br />
<br />
<br />
Step #2 calls the toolbox.sh wrapper scripts which works around the SSE <br />
disabling gcc warning - which happens for GCC < 4.5 (as in the AOSP prebuilt X86 <br />
toolchain).<br />
<br />
This script adds the " -mfpmath=387 -fno-pic" in case it is an X86 and that in <br />
turn eliminates the compilation errors seen above.<br />
<br />
To have finer control over the build process, you can use the "toolbox.sh" <br />
wrapper and set some other stuff without modifying the script files.<br />
<br />
An example for building the same emulator is below:<br />
<br />
# Set arch<br />
export ARCH=x86<br />
# Have make refer to the QEMU wrapper script for building android over x86 <br />
(eliminates the errors listed above)<br />
export <br />
CROSS_COMPILE=${ANDROID_BUILD_TOP}/external/qemu/distrib/kernel-toolchain/android-kernel-toolchain-<br />
# Put your cross compiler here. I am using the AOSP prebuilt one in this example<br />
export <br />
REAL_CROSS_COMPILE=${ANDROID_BUILD_TOP}/prebuilt/linux-x86/toolchain/i686-android-linux-4.4.3/bin/i686-android-linux-<br />
# Configure your kernel - here I am taking the default goldfish_defconfig<br />
make goldfish_defconfig<br />
# build<br />
make -j64<br />
# Run emulator:<br />
emulator -kernel arch/x86/boot/bzImage -show-kernel<br />
<br />
<br />
This works for the 2.6.29 goldfish branch. If anyone is using the emulator with <br />
a 3+ kernel I would be like to hear about it.<br />
<br />
<br />
[[Category:Android]]</div>Vapierhttps://elinux.org/index.php?title=Android_Build_System&diff=387321Android Build System2015-08-13T10:48:53Z<p>Vapier: update git link</p>
<hr />
<div>Basics of the Android Build system were described at ('''Down as of 9/2011'''):<br />
http://source.android.com/porting/build_system.html<br />
<br />
''Note that "partner-setup" should be replaced with "choosecombo" or even "lunch" in that description.''<br />
<br />
(''This information seems to be duplicated at:<br />
http://pdk.android.com/online-pdk/guide/build_system.html<br />
I'm going to assume that the source.android site is the most up-to-date, but I haven't checked.)<br />
<br />
More information about the Android build system, and some of the rationale for it, are described<br />
at:<br />
https://android.googlesource.com/platform/build/+/master/core/build-system.html<br />
<br />
You use build/envsetup.sh to set up a "convenience environment" for working on the<br />
Android source code. This file should be source'ed into your current shell environment.<br />
After doing so you can type 'help' (or 'hmm') for a list of defined functions which are helpful<br />
for interacting with the source.<br />
<br />
== Overview ==<br />
The build system uses some pre-set environment variables and a series of 'make' files<br />
in order to build an Android system and prepare it for deployment to a platform.<br />
<br />
Android make files end in the extension '.mk' by convention, with the ''main'' make file<br />
in any particular source directory being named 'Android.mk'.<br />
<br />
There is only one official file named 'Makefile', at the top of the source tree for the whole repository. You set some environment variables, then type 'make' to build stuff. You can add some options to the make command line (other targets) to turn on verbose output, or perform different actions.<br />
<br />
The build output is placed in 'out/host' and 'out/target' Stuff under 'out/host' are things<br />
compiled for your host platform (your desktop machine). Stuff under 'out/target/product/<platform-name>' eventually makes it's way to a target device (or emulator).<br />
<br />
The directory 'out/target/product/<platform-name>/obj' is used for staging "object" files, which<br />
are intermediate binary images used for building the final programs. Stuff that actually lands in<br />
the file system of the target is stored in the directories root, system, and data, under<br />
'out/target/product/<platform-name>'. Usually, these are bundled up into image files called<br />
system.img, ramdisk.img, and userdata.img.<br />
<br />
This matches the separate file system partitions used on most Android devices.<br />
<br />
== Some Details ==<br />
=== What tools are used ===<br />
During the build you will be using 'make' to control the build steps themselves. A host<br />
toolchain (compiler, linker and other tools) and libraries will be used to build programs<br />
and tools that will run on the host. A different toolchain is used to compile the C and<br />
C++ code that will wind up on the target (which is an embedded board, device or the emulator).<br />
This is usually a "cross" toolchain that runs on an X86 platform, but produces code for some other<br />
platform (most commonly ARM). The kernel is compiled as a standalone binary (it does not use<br />
a program loader or link to any outside libraries). Other items, like native programs (e.g. init or toolbox), daemons or libraries will link against bionic or other system libraries.<br />
<br />
You will be using a Java compiler and a bunch of java-related tools to build<br />
most of the application framework, system services and Android applications themselves.<br />
Finally, tools are used to package the applications and resource files, and to <br />
create the filesystem images that can be installed on a device or used with the simulator.<br />
<br />
=== Telling the system where the Java toolchain is ===<br />
Before you build anything, you have to tell the Android build system where your Java SDK<br />
is. (Installing a Java SDK is a pre-requisite for building).<br />
<br />
Do this by setting a JAVA_HOME environment variable.<br />
<br />
=== Specifying what to build ===<br />
In order to decide what to build, and how to build it, the build system requires that some<br />
variables be set. Different products, with different packages and options can<br />
be built from the same source tree. The variables to control this can be set via a file<br />
with declarations of 'make' variables, or can be specified in the environment.<br />
<br />
A device vendor can create definition files that describe what is to be included on<br />
a particular board or for a particular product. The definition file is called:<br />
buildspec.mk, and it is located in the top-level source directory. You can edit this<br />
manually to hardcode your selections.<br />
<br />
If you have a buildspec.mk file, it sets all the make variables needed for a build, and<br />
you don't have to mess with options.<br />
<br />
Another method of specifying options is to set environment variables. The build system<br />
has a rather ornate method of managing these options for you.<br />
<br />
To set up your build environment, you need to load the variables and functions in build/envsetup.sh.<br />
Do this by 'source-ing' the file into your shell environment, like this:<br />
$ source build/envsetup.sh<br />
or<br />
$ . build/envsetup.sh<br />
<br />
You can type 'help' (or 'hmm') at this point to see some utility functions that are available to make<br />
it easier to work with the source.<br />
<br />
To select the set of things you want to build, and what items to build for, you use either the<br />
'choosecombo' function or the 'lunch' function. 'choosecombo' will walk you through the different<br />
items you have to select, one-by-one, while 'lunch' allows you select some pre-set combinations.<br />
<br />
The items that have to be defined for a build are:<br />
* the product ('generic' or some specific board or platform name)<br />
* the build variant ('user', 'userdebug', or 'eng')<br />
* whether you're running on a simulator ('true' or 'false')<br />
* the build type ('release' or 'debug')<br />
<br />
Descriptions of these different build variants are at http://source.android.com/porting/build_system.html#androidBuildVariants<br />
<br />
The build process from a user perspective is described pretty well in this blog post: [http://blog.codepainters.com/2009/12/18/first-android-platform-build/ First Android platform build] by CodePainters, December 2009<br />
<br />
=== Actually building the system ===<br />
Once you have things set up, you actually build the system with the 'make' command.<br />
<br />
To build the whole thing, run 'make' in the top directory. The build will take a long time, if<br />
you are building everything (for example, the first time you do it).<br />
<br />
== Build tricks ==<br />
=== Seeing the actual commands used to build the software ===<br />
Use the "showcommands" target on your 'make' line:<br />
$ make -j4 showcommands<br />
<br />
This can be used in conjunction with another make target, to see the commands for that build.<br />
That is, 'showcommands' is not a target itself, but just a modifier for the specified build.<br />
<br />
In the example above, the -j4 is unrelated to the showcommands option, and is used to<br />
execute 4 make sessions that run in parallel.<br />
<br />
=== Make targets ===<br />
Here is a list of different make targets you can use to build different parts of the system:<br />
<br />
* make sdk - build the tools that are part of an SDK (adb, fastboot, etc.)<br />
* make snod - build the system image from the current software binaries<br />
* make services<br />
* make runtime<br />
* make droid - make droid is the normal build.<br />
* make all - make everything, whether it is included in the product definition or not<br />
* make clean - remove all built files (prepare for a new build). Same as rm -rf out/<configuration>/<br />
* make modules - shows a list of submodules that can be built (List of all LOCAL_MODULE definitions)<br />
* make <local_module> - make a specific module (note that this is not the same as directory name. It is the LOCAL_MODULE definition in the Android.mk file)<br />
* make clean-<local_module> - clean a specific module<br />
* make bootimage TARGET_PREBUILT_KERNEL=/path/to/bzImage - create a new boot image with custom bzImage<br />
<br />
=== Helper macros and functions ===<br />
There are some helper macros and functions that are installed when you source envsetup.sh. They are documented<br />
at the top of envesetup.sh, but here is information about a few of them:<br />
<br />
* croot - change directory to the top of the tree<br />
* m - execute 'make' from the top of the tree (even if your current directory is somewhere else)<br />
* mm - builds all of the modules in the current directory<br />
* mmm <dir1> ... - build all of the modules in the supplied directories<br />
* cgrep <pattern> - grep on all local C/C++ files<br />
* jgrep <pattern> - grep on all local Java files<br />
* resgrep <pattern> - grep on all local res/*.xml files<br />
* godir <filename> - go to the directory containing a file<br />
<br />
=== Speeding up the build ===<br />
You can use the '-j' option with make, to start multiple threads of make execution concurrently.<br />
<br />
In my experience, you should specify about 2 more threads than you have processors on your machine.<br />
If you have 2 processors, use 'make -j4', If they are hyperthreaded (meaning you have 4 virtual<br />
processors), try 'make -j6.<br />
<br />
You can also specify to use the 'ccache' compiler cache, which will speed up things once you have<br />
built things a first time. To do this, specify 'export USE_CCACHE=1' at your shell command line.<br />
(Note that ccache is included in the prebuilt section of the repository, and does not have to be<br />
installed on your host separately.)<br />
<br />
=== Building only an individual program or module ===<br />
If you use build/envsetup.sh, you can use some of the defined functions to build<br />
only a part of the tree. Use the 'mm' or 'mmm' commands to do this.<br />
<br />
The 'mm' command makes stuff in the current directory (and sub-directories, I believe).<br />
With the 'mmm' command, you specify a directory or list of directories, and it builds those.<br />
<br />
To install your changes, do 'make snod' from the top of tree.<br />
'make snod' builds a new system image from current binaries.<br />
<br />
=== Setting module-specific build parameters ===<br />
Some code in Android system can be customized in the way they are built (separate from the build<br />
variant and release vs. debug options). You can set variables that control individual<br />
build options, either by setting them in the environment or by passing them directly to<br />
'make' (or the 'm...' functions which call 'make'.)<br />
<br />
For example, the 'init' program can be built with support for bootchart logging<br />
by setting the INIT_BOOTCHART variable. (See [[Using Bootchart on Android]] for why<br />
you might want to do this.)<br />
<br />
You can accomplish either with:<br />
$ touch system/init/init.c<br />
$ export INIT_BOOTCHART=true<br />
$ make<br />
or<br />
$ touch system/init/init.c<br />
$ m INIT_BOOTCHART=true<br />
<br />
== Makefile tricks ==<br />
These are some tips for things you can use in your own Android.mk files.<br />
<br />
=== build helper functions ===<br />
A whole bunch of build helper functions are defined in the file build/core/definitions.mk<br />
<br />
Try grep define build/core/definitions.mk for an exhaustive list.<br />
<br />
Here are some possibly interesting functions:<br />
* print-vars - shall all Makefile variables, for debugging<br />
* emit-line - output a line during building, to a file<br />
* dump-words-to-file - output a list of words to a file<br />
* copy-one-file - copy a file from one place to another (dest on target?)<br />
<br />
<br />
=== Add a file directly to the output area ===<br />
You can copy a file directly to the output area, without building anything,<br />
using the add-prebuilt-files function.<br />
<br />
The following line, extracted from prebuilt/android-arm/gdbserver/Android.mk<br />
copies a list of files to the EXECUTABLES directory in the output area:<br />
<br />
$(call add-prebuilt-files, EXECUTABLES, $(prebuilt_files))<br />
<br />
== Adding a new program to build ==<br />
=== Steps for adding a new program to the Android source tree ===<br />
* make a directory under 'external'<br />
** e.g. ANDROID/external/myprogram<br />
* create your C/cpp files.<br />
* create Android.mk as clone of external/ping/Android.mk<br />
* Change the names ping.c and ping to match your C/cpp files and program name<br />
* add the directory name in ANDROID/build/core/main.mk after external/zlib as external/myprogram<br />
* make from the root of the source tree<br />
* your files will show up in the build output area, and in system images.<br />
** You can copy your file from the build output area, under out/target/product/..., if you want to copy it individually to the target (not do a whole install)<br />
<br />
See http://www.aton.com/android-native-development-using-the-android-open-source-project/ for a lot more detail.<br />
<br />
== Building the kernel ==<br />
The kernel is "outside" of the normal Android build system (indeed, the kernel is not included by default in the Android Open Source Project). However, there are tools in AOSP for building a kernel.<br />
If you are building the kernel, start on this page: http://source.android.com/source/building-kernels.html<br />
<br />
If you are building the kernel for the emulator, you may also want to look at:<br />
http://stackoverflow.com/questions/1809774/android-kernel-compile-and-test-with-android-emulator<br />
<br />
And, Ron M wrote (on the android-kernel mailing list, on May 21, 2012):<br />
<br />
This post is very old - but nothing has changes as far as AOSP is concerned, so <br />
in case anyone is interested and runs into this problem when building for QEMU:<br />
<br />
There is actually a nice and shorter way to build the kernel for your QEMU <br />
target provided by the AOSP:<br />
<br />
1. cd to your kernel source dir (Only goldfish 2.6.29 works out of the box for the emulator)<br />
<br />
2. ${ANDROID_BUILD_TOP}/external/qemu/distrib/build-kernel.sh -j=64 --arch=x86 --out=$YourOutDir<br />
<br />
3. emulator -kernel ${YourOutDir}/kernel-qemu # run emulator:<br />
<br />
<br />
Step #2 calls the toolbox.sh wrapper scripts which works around the SSE <br />
disabling gcc warning - which happens for GCC < 4.5 (as in the AOSP prebuilt X86 <br />
toolchain).<br />
<br />
This script adds the " -mfpmath=387 -fno-pic" in case it is an X86 and that in <br />
turn eliminates the compilation errors seen above.<br />
<br />
To have finer control over the build process, you can use the "toolbox.sh" <br />
wrapper and set some other stuff without modifying the script files.<br />
<br />
An example for building the same emulator is below:<br />
<br />
# Set arch<br />
export ARCH=x86<br />
# Have make refer to the QEMU wrapper script for building android over x86 <br />
(eliminates the errors listed above)<br />
export <br />
CROSS_COMPILE=${ANDROID_BUILD_TOP}/external/qemu/distrib/kernel-toolchain/android-kernel-toolchain-<br />
# Put your cross compiler here. I am using the AOSP prebuilt one in this example<br />
export <br />
REAL_CROSS_COMPILE=${ANDROID_BUILD_TOP}/prebuilt/linux-x86/toolchain/i686-android-linux-4.4.3/bin/i686-android-linux-<br />
# Configure your kernel - here I am taking the default goldfish_defconfig<br />
make goldfish_defconfig<br />
# build<br />
make -j64<br />
# Run emulator:<br />
emulator -kernel arch/x86/boot/bzImage -show-kernel<br />
<br />
<br />
This works for the 2.6.29 goldfish branch. If anyone is using the emulator with <br />
a 3+ kernel I would be like to hear about it.<br />
<br />
<br />
[[Category:Android]]</div>Vapierhttps://elinux.org/index.php?title=Android_Logging_System&diff=385586Android Logging System2015-07-24T09:09:24Z<p>Vapier: /* Overview */ minor typos</p>
<hr />
<div>This article describes the Android logging system<br />
<br />
== Overview ==<br />
The Android system has a logging facility that allows system-wide logging of information, from applications and system components.<br />
This is separate from the Linux kernel's own logging system, which is accessed using 'dmesg' or '/proc/kmsg'. However, the logging system does store messages in kernel buffers.<br />
<br />
[[image:Android-logging-kmc-kobayashi.png|right|frame|image by Tetsuyuki Kobabayshi, of Kyoto Microcomputer Co.]]<br />
<br />
The logging system consists of:<br />
* a kernel driver and kernel buffers for storing log messages<br />
* C, C++ and Java classes for making log entries and for accessing the log messages<br />
* a standalone program for viewing log messages (logcat)<br />
* ability to view and filter the log messages from the host machine (via eclipse or ddms)<br />
<br />
There are four different log buffers in the Linux kernel, which provide logging for different parts of the system.<br />
Access to the different buffers is via device nodes in the file system, in /dev/log.<br />
<br />
The four log buffers are:<br />
* main - the main application log<br />
* events - for system event information<br />
* radio - for radio and phone-related information<br />
* system - a log for low-level system messages and debugging<br />
<br />
Up until 2010, only the first three logs existed. The system log was created to keep system messages in a separate<br />
buffer (outside of '/dev/log/main') so that a single verbose application couldn't overrun system messages<br />
and cause them to be lost.<br />
<br />
Each message in the log consists of a tag indicating the part of the system or application that the message came from,<br />
a timestamp, the message log level (or ''priority'' of the event represented by the message) and the log message itself.<br />
<br />
All of the log buffers except for 'event' use free-form text messages. The 'event' buffer is a 'binary' buffer,<br />
where the event messages (and event parameters) are stored in binary form. This form is more compact, but requires<br />
extra processing when the event is read from the buffer, as well as a message lookup database, to decode the event strings.<br />
<br />
The logging system automatically routes messages with specific tags into the radio buffer. Other messages are placed<br />
into their respective buffers when the the log class or library for that buffer is used.<br />
<br />
== Kernel driver ==<br />
The kernel driver for logging is called the 'logger'. See [[Android logger]]<br />
<br />
== System and Application logging ==<br />
=== Application log ===<br />
An Android application includes the [http://developer.android.com/reference/android/util/Log.html android.util.Log class], and uses methods of this class to write messages of different priority into the log.<br />
<br />
Java classes declare their tag statically as a string, which they pass to the log method. The log method used indicates the message "severity" (or log level). Messages can be filtered by tag or priority when the logs are processed by retrieval tools (logcat).<br />
<br />
=== Event log ===<br />
Event logs messages are created using [http://developer.android.com/reference/android/util/EventLog.html android.util.EventLog class], which create binary-formatted log messages. Log entries consist of binary tag codes, followed by binary parameters. The message tag codes are stored on the system at: /system/etc/event-log-tags. Each message has the string for the log message, as well as codes indicating the values associated with (stored with) that entry.<br />
<br />
=== System log ===<br />
Many classes in the Android framework utilize the system log to keep their messages separate from (possibly noisy) application log messages. These programs use the android.util.Slog class, with its associated messages.<br />
<br />
In all cases, eventually a formatted message is delivered through the C/C++ library down to the kernel driver, which stores the message in the appropriate buffer.<br />
<br />
== 'log' command line tool ==<br />
There is a 'log' command line tool that can be used to create log entries from<br />
any program. This is built into the 'toolbox' multi-function program.<br />
<br />
The usage for this is:<br />
<br />
USAGE: log [-p priorityChar] [-t tag] message<br />
priorityChar should be one of:<br />
v,d,i,w,e<br />
<br />
== Capturing stdout with logwrapper ==<br />
It is sometimes useful to capture stdout from native applications into the log. There is a utility called<br />
'logwrapper' which can be used to run a program, and redirect it's stdout into log messages.<br />
<br />
The logwrapper usage is:<br />
Usage: logwrapper [-x] BINARY [ARGS ...]<br />
<br />
Forks and executes BINARY ARGS, redirecting stdout and stderr to<br />
the Android logging system. Tag is set to BINARY, priority is<br />
always LOG_INFO.<br />
<br />
-x: Causes logwrapper to SIGSEGV when BINARY terminates<br />
fault address is set to the status of wait()<br />
<br />
Source for logwrapper is at: system/core/logwrapper/logwrapper.c<br />
<br />
== Logcat command ==<br />
You can use the 'logcat' command to read the log. This command is located in /system/bin<br />
in the local filesystem, or you can access the functionality using the 'adb logcat' command.<br />
<br />
Documentation on the use of this command is at:<br />
http://developer.android.com/guide/developing/tools/adb.html<br />
<br />
Some quick notes:<br />
* Log messages each have a tag and priority.<br />
** You can filter the messages by tag and log level, with a different level per tag.<br />
* You can specify (using a system property) that various programs emit their stdout or stderr to the log.<br />
<br />
=== Trick to couple Android logging to Linux kernel logging ===<br />
Note that the android logging system is completely separate from<br />
the Linux kernel log system (which uses printk inside the kernel<br />
to save messages and dmesg to extract them). You can write to<br />
the kernel log from user space by writing to /dev/kmsg.<br />
<br />
I've seen a reference to couple the two together, to redirect<br />
android messages into the kernel log buffer, using the 'logcat'<br />
program launched from init, like below:<br />
<br />
service logcat /system/bin/logcat -f /dev/kmsg <br />
oneshot<br />
<br />
(See http://groups.google.com/group/android-kernel/browse_thread/thread/87d929863ce7c29e/f8b0da9ed6376b2f?pli=1)<br />
<br />
I'm not sure why you'd want to do this (maybe to put all messages into a <br />
single stream? With the same timestamp, if kernel message timestamping is on?)<br />
<br />
== Resources ==<br />
* [http://developer.android.com/guide/developing/tools/adb.html Android Debug Bridge reference page] - has 'adb logcat' usage information<br />
* [http://blog.kmckk.com/archives/2936958.html Logging System Of Android] Presentation by Tetsuyuki Kobayashi, September, 2010 at CELF's [[Japan Technical Jamboree 34]]<br />
<br />
[[Category:Android]]</div>Vapierhttps://elinux.org/index.php?title=Android_Kernel_Features&diff=385581Android Kernel Features2015-07-24T08:50:26Z<p>Vapier: tweak binder description</p>
<hr />
<div>== Kernel features unique to Android ==<br />
In the course of development, Google developers made some changes to the Linux kernel. The amount<br />
of changes is not extremely large, and is on the order of changes that are customarily made to<br />
the Linux kernel by embedded developers (approximately 250 patches, with about 3 meg. of<br />
differences in 25,000 lines). The changes include a variety of large and small additions, ranging<br />
from the wholesale addition of a flash filesystem (YAFFS2), to very small patches to augment Linux<br />
security (paranoid networking patches).<br />
<br />
Various efforts have been made over the past few years to submit these to changes to mainline<br />
(mostly by Google engineers, but also by others), with not much success so far.<br />
<br />
=== Resources ===<br />
A very good overview of the changes is available in a talk by John Stultz at ELC 2011.<br />
(The talk has a somewhat misleading name.)<br />
* [[Media:Elc2011_stultz.pdf|Android OS for Servers]]- John Stultz, ELC 2011<br />
** This talks breaks down the differences between an Android Linux kernel and a stock Linux kernel, and provides information about the features of each.<br />
* http://www.lindusembedded.com/blog/2010/12/07/android-linux-kernel-additions/<br />
** Lindus Embedded (Alex Gonzalez) has a listing of kernel changes based on an Android kernel for the Freescale MX51 SOC, with some good information about each change.<br />
* http://yidonghan.wordpress.com/2010/01/28/porting-android-to-a-new-device/<br />
** Peter McDermott's excellent description of his work to port Android to the Nokia N810.<br />
** Also, see his annotated list of modified and added kernel files, at: http://www.linuxfordevices.com/files/misc/porting-android-to-a-new-device-p3.html<br />
** See the project site [http://android-n810.sourceforge.net/ at sourceforge].<br />
* http://www.slideshare.net/jollen/android-os-porting-introduction<br />
** Jollen Chen's excellent presentation on system-level Android features, including an overview of kernel features unique to Android: ''Note: Parts of the presentation are in Chinese''<br />
<br />
=== Temporary including in mainline 'staging' ===<br />
Some changes were temporarily added at the "staging" driver area in the stock kernel, but were removed due to lack of support. See [http://www.kroah.com/log/linux/staging-status-12-2009.html Greg KH blog post on -staging for 2.6.33], where he announces the '''removal''' of various Android drivers from -staging.<br />
<br />
=== Android mainlining project ===<br />
Several groups and individuals are working to get kernel changes from Android mainlined into the Linux kernel.<br />
<br />
Please see [[Android Mainlining Project]] for more information.<br />
<br />
== List of kernel features unique to Android ==<br />
Here is a list of changes/addons that the Android Project made to the linux kernel.<br />
As of September, 2011, these kernel changes are not part of the standard kernel and are only available in the Android kernel trees in the Android Open Source project.<br />
<br />
This list does not include board- or platform-specific support or drivers (commonly called "board support").<br />
<br />
=== Binder ===<br />
Binder is an Android-specific interprocess communication mechanism, and remote procedure call system similar to DBus.<br />
<br />
See [[Android Binder]]<br />
<br />
=== ashmem ===<br />
* ashmem - Android shared memory<br />
** implementation is in <tt>mm/ashmem.c</tt><br />
<br />
According to the Kconfig help "The ashmem subsystem is a new shared memory allocator,<br />
similar to POSIX SHM but with different behavior and sporting a simpler file-based API."<br />
<br />
Apparently it better-supports low memory devices, because it can discard<br />
shared memory units under memory pressure.<br />
<br />
To use this, programs open /dev/ashmem, use mmap() on it, and can perform one<br />
or more of the following ioctls:<br />
<br />
* ASHMEM_SET_NAME<br />
* ASHMEM_GET_NAME<br />
* ASHMEM_SET_SIZE<br />
* ASHMEM_GET_SIZE<br />
* ASHMEM_SET_PROT_MASK<br />
* ASHMEM_GET_PROT_MASK<br />
* ASHMEM_PIN<br />
* ASHMEM_UNPIN<br />
* ASHMEM_GET_PIN_STATUS<br />
* ASHMEM_PURGE_ALL_CACHES<br />
<br />
From a thread on android-platform [http://groups.google.com/group/android-platform/browse_thread/thread/2fa6ba5ef9f81d22/0b91a39d108d02fc source]<br />
<br />
You can create a shared memory segment using:<br />
<pre><br />
fd = ashmem_create_region("my_shm_region", size); <br />
if(fd < 0) <br />
return -1; <br />
data = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); <br />
if(data == MAP_FAILED) <br />
goto out; <br />
</pre><br />
<br />
In the second process, instead of opening the region using the same name, for <br />
security reasons the file descriptor is passed to the other process via binder IPC.<br />
<br />
The libcutils interface for ashmem consists of the following calls: (found in system/core/include/cutils/ashmem.h)<br />
<br />
* int ashmem_create_region(const char *name, size_t size);<br />
* int ashmem_set_prot_region(int fd, int prot);<br />
* int ashmem_pin_region(int fd, size_t offset, size_t len);<br />
* int ashmem_unpin_region(int fd, size_t offset, size_t len);<br />
* int ashmem_get_size_region(int fd);<br />
<br />
=== pmem ===<br />
* PMEM - Process memory allocator<br />
** implementation at: <tt>drivers/misc/pmem.c</tt> with include file at: <tt>include/linux/android_pmem.h</tt><br />
** Brian Swetland says:<br />
<pre><br />
The pmem driver is used to manage large (1-16+MB) physically contiguous<br />
regions of memory shared between userspace and kernel drivers (dsp, gpu,<br />
etc). It was written specifically to deal with hardware limitations of<br />
the MSM7201A, but could be used for other chipsets as well. For now,<br />
you're safe to turn it off on x86.<br />
</pre><br />
<br />
David Sparks wrote the following:<br />
[http://groups.google.com/group/android-framework/msg/06bb9d8c294ce6d7 source]<br />
<pre><br />
2. ashmem and pmem are very similar. Both are used for sharing memory <br />
between processes. ashmem uses virtual memory, whereas pmem uses <br />
physically contiguous memory. One big difference is that with ashmem, <br />
you have a ref-counted object that can be shared equally between <br />
processes. For example, if two processes are sharing an ashmem memory <br />
buffer, the buffer reference goes away when both process have removed <br />
all their references by closing all their file descriptors. pmem <br />
doesn't work that way because it needs to maintain a physical to <br />
virtual mapping. This requires the process that allocates a pmem heap <br />
to hold the file descriptor until all the other references are closed. <br />
<br />
3. You have the right idea for using shared memory. The choice between <br />
ashmem and pmem depends on whether you need physically contiguous <br />
buffers. In the case of the G1, we use the hardware 2D engine to do <br />
scaling, rotation, and color conversion, so we use pmem heaps. The <br />
emulator doesn't have a pmem driver and doesn't really need one, so we <br />
use ashmem in the emulator. If you use ashmem on the G1, you lose the <br />
hardware 2D engine capability, so SurfaceFlinger falls back to its <br />
software renderer which does not do color conversion, which is why you <br />
see the monochrome image. <br />
</pre><br />
<br />
=== logger ===<br />
* logger - system logging facility<br />
** This is the kernel support for the 'logcat' command<br />
** The kernel driver for the serial devices for logging are in the source code <tt>drivers/misc/logger.c</tt><br />
** See [[Android logger]] for more information about the kernel code<br />
** See [[Android Logging System]] for an overview of the system it supports<br />
<br />
=== wakelocks ===<br />
* wakelock - used for power management files <tt>kernel/power/wakelock.c</tt><br />
** Holds machine awake on a per-event basis until wakelock is released<br />
** See [[Android Power Management]] for detailed information<br />
<br />
=== oom handling ===<br />
* oom handling modifications<br />
** lowmem notifications<br />
** implementation at: <tt>drivers/misc/lowmemorykiller.c</tt><br />
** also at: <tt>security/lowmem.c</tt><br />
<br />
Informally known as the Viking Killer, the OOM handler simply kills processes as available memory becomes low. The kernel module follows rules for this that are supplied from user space in two ways:<br />
<br />
1. init writes information about memory levels and associated classes:<br />
<br />
* The write value must be consistent with the above properties.<br />
* Note that the driver only supports 6 slots, so we have combined some of the classes into the same memory level; the associated processes of higher classes will still be killed first.<br />
** From /init.rc:<br />
write /sys/module/lowmemorykiller/parameters/adj 0,1,2,4,7,15<br />
write /sys/module/lowmemorykiller/parameters/minfree 2048,3072,4096,6144,7168,8192<br />
<br />
2. User space sets the oom_adj of processes to put them in the correct class for their current operation. This redefines the meaning of oom_adj from that used by the standard OOM killer to something that is more aggressive and controlled.<br />
<br />
These oom_adj levels end up being based on the process lifecycle defined here:<br />
http://developer.android.com/guide/topics/fundamentals.html#proclife<br />
<br />
=== Alarm timers ===<br />
This is the kernel implementation to support Android's AlarmManager. It lets user space tell the kernel when it would like to wake up, allowing the kernel to schedule that appropriately and come back (holding a wake lock) when the time has expired regardless of the sleep state of the CPU.<br />
<br />
==== POSIX Alarm Timers ====<br />
Note that POSIX Alarm timers, which implement this functionality (but not identically), was<br />
accepted into mainline Linux in kernel version 3.0.<br />
<br />
See [https://lwn.net/Articles/429925/ Waking Systems from Suspend] and http://lwn.net/Articles/439364/<br />
<br />
=== paranoid network security===<br />
* paranoid network security<br />
** See [[Android_Security#Paranoid_network-ing]]<br />
<br />
=== timed output / timed gpio ===<br />
Generic gpio is a mechanism to allow programs to access and manipulate gpio registers from user space.<br />
<br />
Timed output/gpio is a system to allow chaning a gpio pin and restore it automatically after a specified timeout.<br />
See <tt>drives/misc/timed_output.c</tt> and <tt>drives/misc/timed_gpio.c</tt><br />
This expose a user space interface used by the vibrator code.<br />
<br />
On ADP1, there is a driver at:<br />
<pre><br />
# cd /sys/bus/platform/drivers/timed-gpio<br />
# ls -l<br />
--w------- 1 0 0 4096 Nov 13 02:11 bind<br />
lrwxrwxrwx 1 0 0 0 Nov 13 02:11 timed-gpio -> ../../../../devices/platform/timed-gpio<br />
--w------- 1 0 0 4096 Nov 13 02:11 uevent<br />
--w------- 1 0 0 4096 Nov 13 02:11 unbind<br />
</pre><br />
<br />
Also, there is a device at:<br />
<pre><br />
# cd /sys/devices/platform/timed-gpio<br />
# ls -lR<br />
.:<br />
lrwxrwxrwx 1 0 0 0 Nov 13 01:34 driver -> ../../../bus/platform/drivers/timed-gpio<br />
-r--r--r-- 1 0 0 4096 Nov 13 01:34 modalias<br />
drwxr-xr-x 2 0 0 0 Nov 13 01:34 power<br />
lrwxrwxrwx 1 0 0 0 Nov 13 01:34 subsystem -> ../../../bus/platform<br />
-rw-r--r-- 1 0 0 4096 Nov 13 01:34 uevent<br />
<br />
./power:<br />
-rw-r--r-- 1 0 0 4096 Nov 13 01:34 wakeup<br />
</pre><br />
<br />
=== RAM_CONSOLE ===<br />
This allows saving the kernel printk messages to a buffer in RAM, so that after a kernel panic<br />
they can be viewed in the next kernel invocation, by accessing /proc/last_kmsg.<br />
<br />
[Would be good to get more details on how to set this up and use it here!]<br />
[I guess this is something like pramfs?]<br />
<br />
=== other kernel changes ===<br />
Here is a miscellaneous list of other kernel changes in the mistral Android kernel:<br />
* switch events - drivers/switch/* userspace support for monitoring GPIO via sysfs/uevent used by vold to detect USB<br />
* USB gadget driver for ADB - drivers/usb/gadget/android.c<br />
* yaffs2 flash filesystem<br />
* support in FAT filesystem for FVAT_IOCTL_GET_VOLUME_ID<br />
* and more...<br />
<br />
== Kernel configuration options ==<br />
The file [http://android.git.kernel.org/?p=kernel/common.git;a=blob_plain;f=Documentation/android.txt;hb=HEAD Documentation/android.txt] has a list of required configuration options for a kernel to support<br />
an Android system.<br />
<br />
[[Category:Android]]</div>Vapierhttps://elinux.org/index.php?title=CELF_Project_Proposal/Create_tool_to_edit_ihex_or_srec_files&diff=38803CELF Project Proposal/Create tool to edit ihex or srec files2011-03-22T23:50:29Z<p>Vapier: /* Comments */ still dont get it</p>
<hr />
<div>; Summary : Upgrade an existing Hex editor to be able to read/write Intel Hex and Motorola S-record files<br />
<br />
; Proposer : Frieder Ferlemann<br />
<br />
<br />
== Description ==<br />
The ihex and srec formats can have an important role in an embedded developers<br />
toolchain. The formats specify both the addresses and the<br />
corresponding data, thus allowing to specify specific ranges<br />
of data which are to be modified. While editors for binary<br />
files exist for linux they all seem to lack import and export<br />
functionality for these formats.<br />
<br />
Reading two files consecutively should result in a hexadecimal<br />
display like:<br />
<br />
00000000 02 00 08 80 fe 75 81 07 12 00 78 e5 82 ... ..u....x..<br />
00000010 60 03 02 00 03 79 00 e9 44 00 60 1b 7a 00 90 00 `....y..D.`.z...<br />
<br />
where the corresponding bytes are either highlighted (when<br />
the definition in the 1st file differs from the 2nd file),<br />
normal (if same), obmitted or greyed out (if there is no<br />
definition in either of the files), be in color1 if only<br />
defined in the 1st file and color2 if only defined in the 2nd.<br />
<br />
Writing a selection of the buffer (lets assume byte 0x000b to 0x000f<br />
in the example above) to an .hex or .s19 file should be possible<br />
starting with offset 0x000b, 0x0000 or a user specified address.<br />
<br />
If you own any kind of consumer electronics product<br />
it's likely that these file formats were involved.<br />
<br />
Text tools (srecord, binutils) for these formats exist but might<br />
present an inhibition for developers which are used to a graphical<br />
toolchain on other platforms.<br />
<br />
Embedded developers targetting these devices (especially 8-bit targets)<br />
typically do not use Linux as a host platform. If there is a win over<br />
then I'd hope for better linux support (f.e. upgrading the firmware<br />
of some of these devices would not require buying the license of<br />
another operating system) and I'd hope for more openness with respect<br />
to protocols and linux drivers.<br />
<br />
An anecdotical contribution relating to the importance of having<br />
developers for a specific platform: http://www.youtube.com/watch?v=8To-6VIJZRE<br />
<br />
; Outlook : In the long run it might be possible to interface to flashprogrammers.<br />
<br />
<br />
== Related work ==<br />
* okteta http://utils.kde.org/projects/okteta/<br />
* srecord http://srecord.sf.net<br />
* others http://en.wikipedia.org/wiki/Comparison_of_hex_editors<br />
* flashrom http://www.coreboot.org/Flashrom<br />
<br />
Related request: A five year old request for khexedit (predecessor of okteta), 20 votes<br />
http://bugs.kde.org/show_bug.cgi?id=94361<br />
<br />
Persons to contact:<br />
* Friedrich W. H. Kossebau (okteta)<br />
* Peter Miller (SRecord)<br />
<br />
; Scope : 2 weeks+ (depending on the internal structure of the hex editor)<br />
<br />
== Comments ==<br />
Wolfgang Denk wrote:<br />
<pre><br />
Hm... is this really needed? Ignoring the often existing restrictions<br />
like segment structure, alignment to flash erase blocks etc. in an<br />
image file (which render such image editing useless and can be dealt<br />
with easier by regenerating the files through a normal build<br />
process), typical image conversions / manipulations can be performed<br />
often quite easily by combinations of standard tools like objcopy and<br />
the like...<br />
<br />
I doubt that a general purpose tool can be designed that covers all<br />
potential use cases, and combinations of the already existing tools<br />
are usually pretty efficient.<br />
</pre><br />
----<br />
Mike Frysinger wrote:<br />
<pre><br />
if you want something to just edit files, how about:<br />
objcopy -I ihex -O binary "$1" "$1.tmp" && khexedit "$1.tmp" &&<br />
objcopy -I binary -O ihex "$1.tmp" "$1" && rm -f "$1.tmp"<br />
</pre><br />
----<br />
Frieder Ferlemann wrote:<br />
<br />
<pre><br />
> Hm... Is this really needed?<br />
<br />
Short answer: Yes, these formats were implemented for a reason.<br />
<br />
Long answer falls into 3 parts which basically say: a) others seem<br />
to need it, b) others implemented it, c) plausible usage scenarios<br />
exist<br />
<br />
Ad a) there were some votes for the bugs.kde.org request<br />
<br />
Ad b) rethorical question: should the authors of<br />
(http://www.hexedit.com/ http://www.kibria.de/frhed.html<br />
http://www.dataman.com/ http://www.conitec.net/ ....)<br />
be informed that they should drop intel hex/motorola s19<br />
support as that feature is a non-issue?<br />
<br />
Ad c) Take an 8-bit device with an 1k bootloader, a serial number,<br />
a program and calibration data crammed into 8k<br />
(or 16k/32k/64k if you are lucky - evidently this is not<br />
a linux target:)<br />
How do you to communicate the following usage cases:<br />
1) upgrade only the program, 2) upgrade calibration data<br />
but not the program, 3) upgrade bootloader, program and<br />
calibration data but do not the touch serial number,<br />
4) upgrade bootloader and program but do not the touch<br />
serial number and do not touch calibration data.<br />
This *can* be the matter of transmitting a *single* .hex or .s19<br />
file respectively!<br />
(you can do with binary files and some binutils/srecord scripts<br />
too but you'd have to talk the customer into installing<br />
some tools in a Windows environment first, possibly get around<br />
limitations in command line length in above mentioned environment<br />
and then try to educate the customer to run a batch file from<br />
some directory where some files should reside and then feed<br />
the resulting file somewhere else. For one or the other reason<br />
one probably wouldn't do this for long:)<br />
Or consider a binary file with the content of the nonvolatile<br />
CMOS memory on a PC in which you'd want someone else (or a<br />
group of people) to set two bytes at two different positions<br />
to a specific value: You can tell to load the binary file into<br />
the editor, then load the .hex/.s19 file over it, then save<br />
again as binary.<br />
<br />
At least being able to view and compare these files visually would be<br />
helpful. (Yes I know objcopy (I did mention binutils in the proposal),<br />
srecord, hexdump and diff/tkdiff/kdiff3/xxdiff/kompare/winmerge))<br />
</pre><br />
<br />
----<br />
Mike Frysinger wrote:<br />
<pre><br />
Your examples don't really sound like justification to me. It sounds<br />
like you simply need a tiny amount of metadata surrounding the transfer<br />
to communicate whatever needs updating. Plus, how is this relevant at<br />
all to "tool for editing files"? Plus plus, you yourself already said<br />
there are multiple tools that can already edit ihex/srec files natively.<br />
<br />
I don't see anything new/useful/innovative in this proposal.<br />
</pre><br />
<br />
[[Category:Project proposals]]</div>Vapierhttps://elinux.org/index.php?title=CELF_Project_Proposal/Complete_hardware,_use-case_handling_in_ALSA&diff=38797CELF Project Proposal/Complete hardware, use-case handling in ALSA2011-03-22T23:47:00Z<p>Vapier: put scope into its own section, and add note about "portability"</p>
<hr />
<div>; Summary : Complete ALSA hardware scenario/use case support in alsa-lib and salsa-lib<br />
<br />
; Proposer : Liam Girdwood<br />
<br />
== Description ==<br />
Modern mobile devices are increasingly required to provide a rich set of<br />
audio functionality required by today's applications. ALSA currently<br />
lacks a portable and high level API to configure audio hardware function<br />
and signal routing.<br />
<br />
e.g. there is no portable method atm to configure the audio hardware to<br />
make a "handset gsm phone call" or "handset voip phone call", etc.<br />
<br />
This purpose of this project would be to complete the ALSA scenario<br />
manager API and get it accepted upstream in alsa-lib and salsa-lib. The<br />
code is nearly ready for upstream, with some work required on it's file<br />
format as the main piece of outstanding work.<br />
<br />
== Related Work ==<br />
More Info:<br />
* http://www.slimlogic.co.uk/?p=40<br />
<br />
API header:<br />
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=include/ascenario.h;h=b1395515b035629d09cd9b3d3a224743053aa159;hb=ascenario<br />
<br />
Development branch now hosted as alsa-lib branch here:<br />
* http://git.alsa-project.org/?p=alsa-lib.git;a=shortlog;h=ascenario<br />
<br />
== Scope ==<br />
<br />
This project will probably take between 2 - 4 weeks.<br />
<br />
== Comments ==<br />
<br />
I don't think "portable" is correct. If you're using ALSA, your code is already "non-portable" since it's specific to ALSA which means it's specific to Linux. ALSA itself works in all Linux deployments.<br />
<br />
[[Category:Project proposals]]</div>Vapierhttps://elinux.org/index.php?title=CELF_Project_Proposal/Extend_DLNA_specifications&diff=38791CELF Project Proposal/Extend DLNA specifications2011-03-22T23:44:55Z<p>Vapier: /* Scope */ fix spelling typo</p>
<hr />
<div>; Summary : Extend the DLNA specifications<br />
<br />
; Proposer : Benjamin Zores<br />
<br />
== Description ==<br />
DLNA has become a de-facto standard for multimedia content <br />
access among Home consumers devices (TVs, NAS, SetTopBox ...).<br />
<br />
Based on UPnP A/V specifications, the DLNA ones however limit its <br />
potential to only a very small subset of multimedia files.<br />
As a result, many files aren't natively "DLNA-compliant" (while <br />
perfectly valid and playable) and require the server to transcode<br />
A/V streams to be streamed. This is actually quite impossible on<br />
embedded devices due to the impressive required CPU processing <br />
resources. See http://gxben.wordpress.com/2008/08/24/why-do-i-hate-dlna-protocol-so-much/ for more details.<br />
<br />
The idea is to get involved with DLNA Alliance to extend the existing <br />
specifications to support more profiles, mainly:<br />
* [http://msdn.microsoft.com/en-us/library/aa451196.aspx Microsoft AVI container]<br />
* [http://www.matroska.org/ Matroska (MKV) container]<br />
* [http://www.xiph.org/ Ogg container and Vorbis audio codec]<br />
* [http://flac.sourceforge.net/ FLAC audio codec]<br />
<br />
The project requires no development but specifications redaction and<br />
companies support fro being accepted by DLNA Alliance members.<br />
<br />
== Related work ==<br />
* libdlna, reference DLNA implementation - http://libdlna.geexbox.org/<br />
<br />
== Scope ==<br />
This should probably take up to 2 months of writing efforts and much more for lobbying.<br />
<br />
== Comments ==<br />
Tim Bird wrote:<br />
<pre><br />
This was discussed at the last OSS DLNA mini-summit, in 2008.<br />
Attendees decided it would be good, but actual progress getting<br />
something put together to submit to DLNA was missing.<br />
</pre></div>Vapierhttps://elinux.org/index.php?title=CELF_Project_Proposal/Create_Bluray_decoding_library&diff=38785CELF Project Proposal/Create Bluray decoding library2011-03-22T23:44:07Z<p>Vapier: /* Comments */ libbluray already exists</p>
<hr />
<div>; Summary : Create an OpenSource Bluray decoding library<br />
<br />
; Proposer : Benjamin Zores<br />
<br />
== Description ==<br />
With recent video decoding acceleration features (VDPAU, <br />
VAAPI and multi-threaded/core decoders), Linux now can compete <br />
efficiently on HomeTheater PC (HTPC) and embedded multimedia SetTopBox <br />
market.<br />
<br />
One remaining drawback is the complete lack of Bluray movies decoding <br />
support. While nearly all video player (FFMpeg, MPlayer, Xine, <br />
Gstreamer, VLC) now are able to demux and decode H.264 & VC-1 MPEG-TS <br />
streams found on Bluray discs, none of them is able to directly read<br />
and decrypt content from an original disc.<br />
<br />
This idea is to create a Bluray access and decrypt library that could be <br />
commonly used by all players. Several steps are required to do so:<br />
* be OS portable and written in C, with embedded constraints in mind.<br />
* support AES, SHA1 and ECC decoding, preferably by native implementation or through GnuTLS.<br />
* decode MPLS playlist file format<br />
* support [http://en.wikipedia.org/wiki/Advanced_Access_Content_System AACS] protection<br />
* support [http://en.wikipedia.org/wiki/BD%2B BD+] protection<br />
* support [http://en.wikipedia.org/wiki/BD-J BD-J] protection (hard, due to JVM)<br />
<br />
Such a library has been initiated but development seems discontinued.<br />
<br />
== Related work ==<br />
* libbluray: http://my-trac.assembla.com/libbluray/<br />
<br />
== Funds ==<br />
* Sponsor Bluray drives to developers<br />
* Buy Bluray association specifications (including protection mechanisms).<br />
<br />
== Scope ==<br />
* Write a new lib based on existing work<br />
* Polish its API for extensive media player projects usage<br />
* Extend the on-the-fly decryption algorithms.<br />
<br />
This should probably take up to a year of development and tests.<br />
<br />
=== Interested parties ===<br />
* Various people from GeeXboX project team already interested<br />
* Probably random developers from MPlayer/Xine/VLC/Gstreamer projects.<br />
<br />
== Comments ==<br />
<br />
If libbluray already exists, multimedia projects have already picked it up, and has a supported community, why should a new one be started? That project seems to still be updated considering patches are going into its git tree.<br />
<br />
[[Category:Project proposals]]</div>Vapierhttps://elinux.org/index.php?title=CELF_Project_Proposal/Kernel_evdev_IR_support&diff=38779CELF Project Proposal/Kernel evdev IR support2011-03-22T23:41:17Z<p>Vapier: /* Comments */ lirc has been mainlined ...</p>
<hr />
<div>; Summary : Add kernel remote control support through evdev.<br />
<br />
; Proposer : Benjamin Zores<br />
<br />
== Description ==<br />
Many STB multimedia embedded devices feature a remote control support.<br />
Based on LIRC, it's always a pain to get the right driver to work with<br />
the right receiver and it's hard to configure and support multiple<br />
remotes on a given system.<br />
<br />
Mainline kernel never get LIRC included but a few remotes currently<br />
are supported, providing a regular evdev interface, acting like a<br />
regular keyboard/mouse controller.<br />
<br />
The idea would be to create some framework for generic remote<br />
handling, with migration from currently LIRC-supported remotes<br />
to new API.<br />
<br />
Some work/patches already have been worked out... See<br />
* http://lwn.net/Articles/364515/ and<br />
* http://lwn.net/Articles/364196/<br />
<br />
== Related work ==<br />
<br />
== Comments ==<br />
<br />
Lirc is in mainline now, albeit in the staging area at the moment.<br />
<br />
; Scope : unknown<br />
<br />
[[Category:Project proposals]]</div>Vapierhttps://elinux.org/index.php?title=CELF_Project_Proposal/Add_pointer_visualization_to_the_kernel_framebuffer&diff=38773CELF Project Proposal/Add pointer visualization to the kernel framebuffer2011-03-22T23:40:22Z<p>Vapier: /* Comments */ i dont get this project</p>
<hr />
<div>; Summary : Add input event mouse/touch pointer visualization on the kernel framebuffer<br />
<br />
; Proposer : Leon Woestenberg <leon@sidebranch.com><br />
<br />
== Description ==<br />
The current kernel framebuffer is an output only interface and<br />
relies on higher level libraries for input/output interaction.<br />
<br />
For truly minimal systems (such as a Flash player running on the<br />
kernel framebuffer)<br />
it is very interesting to visualize mouse and touch events from the<br />
generic input event layer.<br />
<br />
In first instance, this means a mouse pointer drawn on the framebuffer.<br />
<br />
Pitfall: this should not become yet another graphics library. Only a<br />
mouse pointer to see to visualize mouse or touchscreen input events on the framebuffer.<br />
<br />
== Related work ==<br />
* FBUI - http://home.comcast.net/~fbui/<br />
<br />
; Scope : This should take approx. 3 weeks of development and test effort.<br />
<br />
== Comments ==<br />
<br />
Wouldn't the player itself take care of drawing the cursor? After all, everyone wants to theme the cursor in their own way to match whatever output they have. Otherwise, you get into the rabbit hole of the kernel having to maintain the cursor image itself, which gets worse when the cursor is context sensitive (think what happens to the cursor in your web browser as you move over different elements). The kernel sounds like the complete wrong place to handle this.<br />
<br />
[[Category:Project proposals]]</div>Vapierhttps://elinux.org/index.php?title=CELF_Project_Proposal/Refactor_the_Qi_lightweight_bootloader&diff=38767CELF Project Proposal/Refactor the Qi lightweight bootloader2011-03-22T23:35:46Z<p>Vapier: u-boot-v2 is now barebox</p>
<hr />
<div>; Summary : Refactor the Qi lightweight bootloader.<br />
<br />
; Proposer : Matt Hsu<br />
<br />
== Description ==<br />
<br />
Qi (named by Alan Cox on Openmoko kernel list) is a minimal bootloader that<br />
"breathes life" into Linux. Its goal is to stay close to the minimum <br />
needed to "load" and then "boot" Linux -- no boot menus, additional peripheral init<br />
or private states.<br />
<br />
Qi currently supports Samsung s3c24xx series, s3c6410, TI omap3530, and Freescale i.MX31. The<br />
more support platforms are planned to add on. The purpose of this project<br />
would be to improve Qi's maintainability, portability. Ideally, this would<br />
make people spend less time on bootloader development but be more focused<br />
on Linux system.<br />
<br />
Project objectives:<br />
* Make the hierarchy of source files more sensible and clean<br />
* Generalize components which could be used in common such as I2C drivers.<br />
** Example: platform specific I2C driver -> GPIO bitbang driver.<br />
* Remove duplicated, unused code, header definition. Keep Qi as minimum as needed.<br />
<br />
== Related work ==<br />
* http://wiki.openmoko.org/wiki/Qi<br />
<br />
Development branches are hosted here:<br />
* http://git.warmcat.com/cgi-bin/cgit/qi/<br />
* http://gitorious.org/0xlab-bootloader<br />
<br />
; Scope : Unknown<br />
<br />
== Comments ==<br />
<br />
QUESTION: why Qi and not Barebox (u-boot-v2) or [[APEX]]?<br />
<br />
[[Category:Project proposals]]</div>Vapierhttps://elinux.org/index.php?title=Project_Proposals_for_2010&diff=38761Project Proposals for 20102011-03-22T23:34:19Z<p>Vapier: revert previous ... typo is in page name, not link</p>
<hr />
<div>Here is a list of project proposals for 2010, submitted by various people:<br />
<br />
== Boot Time ==<br />
* [[Add bootchart boot logger functionality to busybox]]<br />
<br />
== Boot Technologies ==<br />
* [[CELF Project Proposal/Add DFU support to U-Boot|Add DFU support to U-Boot]]<br />
* [[CELF Project Proposal/Refactor the Qi lightweight bootloader|Refactor the Qi lightweight bootloader]]<br />
* [[CELF Project Proposal/Improve kexecboot|Improve kexecboot]]<br />
* [[CELF Project Proposal/Add IPV6 support to U-Boot|Add IPV6 support to U-Boot]]<br />
* [[CELF Project Proposal/Rework ARM architecture support in U-Boot|Rework ARM architecture support in U-Boot]]<br />
<br />
== Graphics ==<br />
* [[Decrease X.org XFree86 server footprint]]<br />
* [[CELF Project Proposal/Suppress Xvnc dependency on C++|Suppress Xvnc dependency on C++]]<br />
<br />
== Input devices ==<br />
* [[CELF Project Proposal/Add pointer visualization to the kernel framebuffer|Add pointer visualization to the kernel framebuffer]]<br />
* [[CELF Project Proposal/Kernel evdev IR support|Kernel evdev IR support]]<br />
<br />
== Media Handling ==<br />
* [[CELF Project Proposal/Create Bluray decoding library|Create Bluray decoding library]]<br />
* [[CELF Project Proposal/Extend DLNA specifications|Extend DLNA specifications]]<br />
<br />
== Sound ==<br />
* [[CELF Project Proposal/Complete hardware, use-case handling in ALSA|Complete hardware, use-case handling in ALSA]]<br />
<br />
== File systems ==<br />
* [[Add Pramfs filesystem to the kernel mainline]]<br />
* [[CELF Project Proposal/Add LZO compression support to Squashfs|Add LZO compression support to Squashfs]]<br />
* [[CELF Project Proposal/UBIFS mount time speedups|UBIFS mount time speedups]]<br />
<br />
== Power Management ==<br />
* [[CELF Project Proposal/Add behavior-oriented power management|Add behavior-oriented power management]]<br />
<br />
== Realtime ==<br />
* [[CELF Project Proposal/Add sleeping spinlocks to mainline kernel|Add sleeping spinlocks to mainline kernel]]<br />
* [[CELF Project Proposal/Create online training for using RT-preempt|Create online trainning for using RT-preempt]]<br />
<br />
== System Size ==<br />
* [[CELF Project Proposal/Add -ffunction-sections support to Linux kernel|Add -ffunction-sections support to Linux kernel]]<br />
<br />
== Exception Handling ==<br />
* [[CELF Project Proposal/Create a watchdog framework for the Linux kernel|Create a watchdog framework for the Linux kernel]]<br />
<br />
== Tools ==<br />
* [[CELF Project Proposal/Create tool to edit ihex or srec files|Create tool to edit ihex or srec files]]<br />
* [[CELF Project Proposal/Create LabView equivalent for Linux|Create LabView equivalent for Linux]]<br />
* [[CELF Project Proposal/Add Device Tree emulation support to QEMU|Add Device Tree emulation support to QEMU]]<br />
* [[CELF Project Proposal/Create Open Toolbox Platform|Create Open Toolbox Platform]]<br />
* [[CELF Project Proposal/Add pcc support for Linux kernel|Add pcc support for Linux kernel]]<br />
* [[CELF Project Proposal/Combine tcg with tcc|Combine tcg with tcc]]<br />
<br />
== Processor ==<br />
* [[CELF Project Proposal/Implement NUBI ABI for MIPS|Implement NUBI ABI for MIPS]]<br />
<br />
[[Category:Project proposals]]</div>Vapierhttps://elinux.org/index.php?title=Project_Proposals_for_2010&diff=38755Project Proposals for 20102011-03-22T23:33:41Z<p>Vapier: IPV6 -> IPv6</p>
<hr />
<div>Here is a list of project proposals for 2010, submitted by various people:<br />
<br />
== Boot Time ==<br />
* [[Add bootchart boot logger functionality to busybox]]<br />
<br />
== Boot Technologies ==<br />
* [[CELF Project Proposal/Add DFU support to U-Boot|Add DFU support to U-Boot]]<br />
* [[CELF Project Proposal/Refactor the Qi lightweight bootloader|Refactor the Qi lightweight bootloader]]<br />
* [[CELF Project Proposal/Improve kexecboot|Improve kexecboot]]<br />
* [[CELF Project Proposal/Add IPv6 support to U-Boot|Add IPV6 support to U-Boot]]<br />
* [[CELF Project Proposal/Rework ARM architecture support in U-Boot|Rework ARM architecture support in U-Boot]]<br />
<br />
== Graphics ==<br />
* [[Decrease X.org XFree86 server footprint]]<br />
* [[CELF Project Proposal/Suppress Xvnc dependency on C++|Suppress Xvnc dependency on C++]]<br />
<br />
== Input devices ==<br />
* [[CELF Project Proposal/Add pointer visualization to the kernel framebuffer|Add pointer visualization to the kernel framebuffer]]<br />
* [[CELF Project Proposal/Kernel evdev IR support|Kernel evdev IR support]]<br />
<br />
== Media Handling ==<br />
* [[CELF Project Proposal/Create Bluray decoding library|Create Bluray decoding library]]<br />
* [[CELF Project Proposal/Extend DLNA specifications|Extend DLNA specifications]]<br />
<br />
== Sound ==<br />
* [[CELF Project Proposal/Complete hardware, use-case handling in ALSA|Complete hardware, use-case handling in ALSA]]<br />
<br />
== File systems ==<br />
* [[Add Pramfs filesystem to the kernel mainline]]<br />
* [[CELF Project Proposal/Add LZO compression support to Squashfs|Add LZO compression support to Squashfs]]<br />
* [[CELF Project Proposal/UBIFS mount time speedups|UBIFS mount time speedups]]<br />
<br />
== Power Management ==<br />
* [[CELF Project Proposal/Add behavior-oriented power management|Add behavior-oriented power management]]<br />
<br />
== Realtime ==<br />
* [[CELF Project Proposal/Add sleeping spinlocks to mainline kernel|Add sleeping spinlocks to mainline kernel]]<br />
* [[CELF Project Proposal/Create online training for using RT-preempt|Create online trainning for using RT-preempt]]<br />
<br />
== System Size ==<br />
* [[CELF Project Proposal/Add -ffunction-sections support to Linux kernel|Add -ffunction-sections support to Linux kernel]]<br />
<br />
== Exception Handling ==<br />
* [[CELF Project Proposal/Create a watchdog framework for the Linux kernel|Create a watchdog framework for the Linux kernel]]<br />
<br />
== Tools ==<br />
* [[CELF Project Proposal/Create tool to edit ihex or srec files|Create tool to edit ihex or srec files]]<br />
* [[CELF Project Proposal/Create LabView equivalent for Linux|Create LabView equivalent for Linux]]<br />
* [[CELF Project Proposal/Add Device Tree emulation support to QEMU|Add Device Tree emulation support to QEMU]]<br />
* [[CELF Project Proposal/Create Open Toolbox Platform|Create Open Toolbox Platform]]<br />
* [[CELF Project Proposal/Add pcc support for Linux kernel|Add pcc support for Linux kernel]]<br />
* [[CELF Project Proposal/Combine tcg with tcc|Combine tcg with tcc]]<br />
<br />
== Processor ==<br />
* [[CELF Project Proposal/Implement NUBI ABI for MIPS|Implement NUBI ABI for MIPS]]<br />
<br />
[[Category:Project proposals]]</div>Vapierhttps://elinux.org/index.php?title=Squashfs_support_for_MTD_subsystem&diff=38749Squashfs support for MTD subsystem2011-03-22T23:23:38Z<p>Vapier: obsoleted by another proposal ?</p>
<hr />
<div>Squashfs support for MTD subsystem<br />
<br />
; Summary: Squashfs support for MTD subsystem<br />
<br />
; Proposer: Phillip Lougher<br />
<br />
== Description ==<br />
This proposal will add MTD subsystem support to Squashfs,<br />
including bad block handling.<br />
<br />
Squashfs is already widely used on MTD devices (NAND flash etc.)<br />
in embedded systems, however, because Squashfs lacks native MTD support,<br />
this is currently performed via MTD's block device emulation (or via UBI<br />
or stored inside another MTD aware filesystem, i.e. YAFFS2/JFFS2).<br />
These solutions add unnecessary code and run-time overhead, and in the<br />
case of MTD's block device emulation, this lacks bad block support.<br />
<br />
The following two tasks will be undertaken:<br />
<br />
* Write a user-space utility that writes Squashfs filesystems to NAND, skipping bad blocks (and record that bad bocks have been skipped in the out of band data).<br />
<br />
* Re-write the low-level squashfs_read_data() routine in the kernel squashfs code to read directly from NAND using MTD. This will use the out of band data to determine which blocks have been skipped by the user-space utility.<br />
<br />
It is anticipated that a major piece of the work will be the<br />
refactoring of the squashfs_read_data() function and I/O backend<br />
in such a way that MTD support is added cleanly, minimising changes<br />
to existing critical code and without affecting performance.<br />
<br />
== Related work ==<br />
* http://thread.gmane.org/gmane.linux.kernel/962226<br />
<br />
Added MTD handling to Squashfs, without any bad block handling.<br />
Unfortunately, I (the Squashfs maintainer) considered the<br />
patch series to be overly complicated, it unnecessarily<br />
touched too much core code, and removed many performance<br />
optimisations (see http://article.gmane.org/gmane.linux.kernel/965490).<br />
<br />
== Scope ==<br />
About 2 months<br />
<br />
== Contractor Candidates ==<br />
I'm recommending myself, as the author and maintainer of<br />
Squashfs.<br />
<br />
== Comments ==<br />
<br />
Isn't this obsoleted by [[Support read-only block filesystems on MTD flash]]?<br />
<br />
[[Category:Project proposals 2011]]</div>Vapierhttps://elinux.org/index.php?title=Maintain_a_catalog_of_online_Linux_documentation&diff=38743Maintain a catalog of online Linux documentation2011-03-22T23:20:04Z<p>Vapier: add a note about wiki functionality</p>
<hr />
<div>; Summary: Maintain a catalog of online Linux documentation<br />
<br />
; Proposer: Constantine Shulyupin<br />
<br />
== Description ==<br />
<br />
Rob Landley in his article "Where Linux Kernel Documentation Hides",<br />
wrote in 2008:<br />
<br />
Google is great at finding things, but it doesn't tell you what to <br />
search for. Google is not a reference work that allows one to see<br />
available topics and home in on an area of interest, moving from<br />
more general to more specific.<br />
...<br />
Indexing the web's Linux kernel documentation just to provide a<br />
comprehensive reference is a huge undertaking. Even keeping an index<br />
up to date after its creation would be a project on par with any<br />
other major kernel subsystem. But without knowing here the holes are,<br />
writing new documentation to try to fill in those holes tends to<br />
reinvent the wheel.<br />
...<br />
In the absence of an obvious place to go on the web to<br />
find the most up-to-date existing documentation, newly<br />
created documentation tends to be repetitive and overlapping.<br />
<br />
I would like to improve Linux Technology Reference:<br />
http://www.makelinux.net/reference .<br />
It is going to be a comprehensive and easily accessible catalog about<br />
Linux, GNU, FOSS and embedded Linux for developers. It now contains 900+<br />
links to 100+ sites, ordered in 200+ categories. Four top level<br />
categories are: Linux OS - about user space system and applications,<br />
Linux kernel, Embedded Linux and Additional topics (design,<br />
documentation).<br />
<br />
The should be like for Linux like MSDN Library for Windows.<br />
<br />
Planed improvements:<br />
* Adding convenient search capabilities.<br />
* Optionally changing catalog engine.<br />
* Promotion on Linux related sites.<br />
* Periodical updates and expanding. (The last big review was performed two years ego).<br />
* Adding feedback and link submit capabilities.<br />
<br />
== Related work ==<br />
* Linux Technology Reference - http://www.makelinux.net/reference<br />
<br />
== Scope ==<br />
From some weeks to some month, depending on number of changes and budged.<br />
Up to some days each month periodically.<br />
<br />
== Contractor Candidates ==<br />
Constantine Shulyupin (me, the author of the site)<br />
<br />
== Comments ==<br />
* User comments on the site -<br />
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID=3549498&gid=49301<br />
<br />
Rob Landley commented:<br />
<br />
Another question that got raised during the Q&A and which I didn't<br />
manage to competently answer during the talk:<br />
<br />
"Why not just use a Wiki"?<br />
<br />
Wikis are great ways of accumulating a slush pile, but they suck at<br />
indexing content. How do you find anything on wikipedia? Via Google.<br />
Wikipedia is cross-linked out the wazoo but it hasn't even got<br />
alphabetical topic browsing like a print encyclopedia if you wanted to<br />
skim through to see what's there without already knowing what you're<br />
looking for.<br />
<br />
To give newbies a way into the material you need an obvious place to<br />
start. Some kind of overview you can drill down from, which turns out<br />
to be hard to do.<br />
----<br />
<br />
Rob also commented:<br />
<br />
... my immediate question is long-term maintenance.<br />
How do you add new things, how do you check old ones haven't bit-rotted,<br />
and what happens if you're hit by a bus or sidelined by malaria for six<br />
months.<br />
<br />
----<br />
<br />
(1) take the sub way (2) don't go to India<br />
<br />
Wikipedia does have alphabetic indexes, as do many Wiki's. They also have the ability to add tags and browse via that. One example found in 3 seconds: http://en.wikipedia.org/wiki/Category:Disambiguation_pages<br />
<br />
[[Category:Project proposals 2011]]</div>Vapierhttps://elinux.org/index.php?title=Bootloader_Security_Resources&diff=10788Bootloader Security Resources2009-04-13T23:31:59Z<p>Vapier: fix grub wiki level</p>
<hr />
<div>== Overview ==<br />
This page has security information about bootloaders.<br />
<br />
== Technology/Project pages ==<br />
*[[Security]]<br />
*[[Security Hardware Resources]]<br />
<br />
== Security Enhancements ==<br />
There are two methods of booting<br />
*Trusted/Authenticated Boot: just reporting <br />
*Secure Boot: boot can be halted <br />
<br />
=== Trusted Computing Group (TCG) ===<br />
TCG is a hardware-based security solution not only for the PC platform, but also applicable for embedded devices. To understand the TCG, <br />
[https://www.trustedcomputinggroup.org/groups/TCG_1_0_Architecture_Overview.pdf TCG Specification Architecture Overview] is a good document.<br />
<br />
Using the Trusted Platform Module(TPM) security chip and write-protected boot-code, we will be able to implement the Trusted Boot efficiently. Unfortunately, Many existing TPMs are designed for PC Platform, it requires LPC bus. Thus you have to use glue logic to use such TPM with your system. But, Atmel(R) has been released TPM chip, AT97SC3201S which has I2C/SMBus interface.<br />
<br />
== Open Source Projects/Mailing Lists ==<br />
<br />
=== RedBoot/eCos ===<br />
*[http://sources.redhat.com/redboot/ RedBoot] is a complete bootstrap environment for embedded systems. Based on the eCos. Following security enhancement was based on the RedBoot.<br />
*[http://www.ece.uvic.ca/~ece499/2003a/group05/High%20Reliability%20Bootloader%20for%20x86%20-%20Final%20Report.htm High Robustness Bootloader for x86 Platform] provide the capability of having signed program binary images. <br />
<br />
=== U-Boot ===<br />
<br />
Project site: [http://sourceforge.net/projects/u-boot/ u-boot]<br />
<br />
=== GRUB ===<br />
[http://www.gnu.org/software/grub/ GRUB] is a bootloader for PC Platform. There are two patches to enable the TCG's Trusted Boot.<br />
<br />
(In this case, the BIOS must support TCG Trusted Boot)<br />
*[http://www.prosec.rub.de/trusted_grub.html University Bochum, Trusted Grub]<br />
*[http://trousers.sourceforge.net/grub.html TrouSerS, GRUB TCG patch]<br />
<br />
GRUB provides a password feature, only administrator can start the interactive operations.<br />
<br />
=== EtherBoot ===<br />
<br />
[http://www.etherboot.org/ EtherBoot] is a software package for creating ROM images that can download code over an Ethernet network to be executed on an x86 computer. <br />
"[http://wiki.etherboot.org/pmwiki.php/Main/SafeBootMode SafeBootMode] means any NBI image that's downloaded is checked whether it contains a valid digital signature and if not, the user is notified."<br />
<br />
= Other Resources =<br />
* W. A. Arbaugh , D. J. Farber , J. M. Smith, A secure and reliable bootstrap architecture, Proceedings of the 1997 IEEE Symposium on Security and Privacy, p.65, May 04-07, 1997 <br />
* [http://www.missl.cs.umd.edu/sebos.html Security Enhanced Bootloader for Operating Systems]<br />
* [http://www.microsoft.com/whdc/system/platform/pcdesign/secure-start_tech.mspx Technical Overview of Windows Vista - Secure Startup]<br />
<br />
[[Category:Security]]<br />
[[Category:Bootloader Security Resources]]</div>Vapierhttps://elinux.org/index.php?title=Bootloader&diff=10787Bootloader2009-04-13T23:29:57Z<p>Vapier: sort the table alphabetically, add Blackfin to the mix, and use condensed format to make the table easier to read</p>
<hr />
<div>Briefly, a bootloader is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the operating system kernel software (such as the Hurd or the Linux). The kernel, in turn, initializes the rest of the operating system (e.g. GNU).<br />
<br />
== List of bootloaders ==<br />
<br />
<br />
{| class="wikitable"<br />
|+ align="bottom" | Legend: '''?''':Unknown '''-''':Not supported<br />
! Bootloader !! ARM !! BFIN !! MIPS !! PPC !! SH !! x86 || remarks<br />
|-<br />
! [[APEX]]<br />
| y || - || ? || ? || ? || ? ||<br />
|-<br />
! [[Blob]]<br />
| y || - || - || - || - || - ||<br />
|-<br />
! [http://www.linux-mips.org/wiki/Common_Firmware_Environment CFE]<br />
| - || - || y || - || - || - || for specific BroadCom chipsets<br />
|-<br />
! [http://www.coreboot.org/Welcome_to_coreboot coreboot (LinuxBIOS)]<br />
| - || - || - || - || - || y || Conference talk by Peter Stuge at Embedded Linux Conference Europe 2008, [http://free-electrons.com/pub/video/2008/elce/nluug-fall2008-stuge-coreboot.ogv video]<br />
|-<br />
! [[U-Boot|Das U-Boot]]<br />
| y || y || y || y || y || y || allows networked setup<br />
|-<br />
! [[Grub]] <br />
| ? || - || ? || y || ? || y ||<br />
|-<br />
! [[Lilo]] <br />
| - || - || - || - || - || y || x86 only, requires nasm to build<br />
|-<br />
! [http://www.microcross.com/html/micromonitor.html MicroMonitor]<br />
| y || y || ? || y || y || ? ||<br />
|-<br />
! [http://www.linux-mips.org/wiki/PMON_2000 PMON 2000]<br />
| - || - || y || - || - || - ||<br />
|-<br />
! [[RedBoot]]<br />
| y || ? || y || y || y || y || allows networked setup<br />
|-<br />
! [[Syslinux]]<br />
| - || - || - || - || - || y || variants (including) isolinux are very flexible for booting x86<br />
|-<br />
! [http://yaboot.ozlabs.org/ Yaboot]<br />
| - || - || - || y || - || - ||<br />
|-<br />
! [http://www.linux-mips.org/wiki/YAMON YAMON]<br />
| - || - || y || - || - || - ||<br />
|}<br />
<br />
A lot more exhaustive list is available at [http://en.wikipedia.org/wiki/Comparison_of_boot_loaders Wikipedia]<br />
<br />
<br />
== List of legacy boot loaders ==<br />
Please don't pick any of these for new designs!<br />
<br />
* rrload (RidgeRun, used for older TI OMAP boards)<br />
* [http://www.linux-mips.org/wiki/PMON pmon] (used for Linux MIPS, including BroadCom wifi router boards like Linksys)<br />
<br />
== See also ==<br />
<br />
* [[Bootloader_Security_Resources]]<br />
<br />
[[Category:Bootloaders]]</div>Vapierhttps://elinux.org/index.php?title=Android&diff=10762Android2009-04-13T08:19:16Z<p>Vapier: fix up broken wiki formatting</p>
<hr />
<div>== Overview ==<br />
<br />
Android ([http://en.wikipedia.org/wiki/Google_Android wikipedia entry]) a software platform and operating system written by Google and the Open Handset Alliance, designed for use in small form factor devices and smartphones.<br />
<br />
See [[Android Notes]] for miscellaneous notes on Android.<br />
<br />
See [[Android on OMAP]] for tips for putting Android on OMAP-based platforms.<br />
<br />
== Stack ==<br />
* [http://developer.android.com/images/system-architecture.jpg Android Stack]<br />
* http://developer.android.com/guide/basics/what-is-android.html<br />
<br />
== Devices ==<br />
<br />
=== Production ===<br />
* HTC Dream as the T-Mobile G1 and the Google ADP1<br />
* HTC Magic<br />
<br />
=== Community Ports ===<br />
* [[OpenMoko|OpenMoko Freerunner]]</div>Vapierhttps://elinux.org/index.php?title=Logic_Analyzers&diff=10761Logic Analyzers2009-04-13T08:10:32Z<p>Vapier: new page for logic analyzer tools</p>
<hr />
<div>A logic analyzer is an electronic instrument that displays signals in a digital circuit that are too fast to be observed and presents it to a user so that the user can more easily check correct operation of the digital system. They are typically used for capturing data in systems that have too many channels to be examined with an oscilloscope. Software running on the logic analyzer can convert the captured data into timing diagrams, protocol decodes, state machine traces, assembly language, or correlate assembly with source-level software.<br />
<br />
When selecting a logic analyzer, make sure that the software package includes bus analyzers (I2C/SPI/UART are a given). Any tool worth purchasing will include support for these.<br />
<br />
= Tools =<br />
<br />
Since logic analyzers typically need software running on your development system, this list is split up to give preference to those tools which are fully supported on both Windows and Linux.<br />
<br />
== Linux ==<br />
* [http://www.bitscope.com/ BitScope]<br />
* [http://minila.sourceforge.net/ miniLA] - open source hardware!<br />
<br />
== Everyone Else ==<br />
* [http://www.acute.com.tw/ Acute]<br />
* [http://tools.asix.net/dbg_sigma.htm ASIX]<br />
* [http://www.saleae.com/ Saleae]<br />
* [http://www.tech-tools.com/dv_main.htm TechTools]<br />
<br />
= Information =<br />
* http://en.wikipedia.org/wiki/Bus_analyzer<br />
* http://en.wikipedia.org/wiki/Logic_analyzer<br />
<br />
[[Category:Development Tools]]</div>Vapierhttps://elinux.org/index.php?title=JTAG&diff=10760JTAG2009-04-13T07:45:54Z<p>Vapier: add some more jtag devices and the urjtag software package</p>
<hr />
<div>Joint Test Action Group, referring to IEEE Standard 1149.1: Four-pin (plus power/ground) interface designed to test connections between chips. Interface is serial (clocked via the TCK pin). Configuration is performed by manipulating a state machine one bit at a time (via TMS pin), then transferring one bit of data in and out per TCK clock (via TDI and TDO pins, respectively). Different instruction modes can be loaded to read the chip ID, sample input pins, drive (or float) output pins, manipulate chip functions, or bypass (pipe TDI to TDO to logically shorten chains of multiple chips). Operating frequency varies per chip, but is typically 10-100MHz TCK (10-100ns per bit time). The description of how JTAG is implemented for a specific device is described in a file specific to that device called a [[BSDL]] file.<br />
<br />
=== Information ===<br />
* http://en.wikipedia.org/wiki/JTAG<br />
* http://www.asset-intertech.com/products/free_resources.htm - various resources<br />
* [http://www.openjtag.net openjtag wiki]<br />
* [[media:JTAGpinouts.pdf|Common JTAG Pinouts]]<br />
<br />
=== Tutorial ===<br />
[[Media:boundryscan_tutorial.pdf|Tutorial from Asset Intertech]]<br />
<br />
=== Hardware (emulators) ===<br />
* [[Holly Gates]] wiggler - Parallel Port<br />
* [[Cheap Tag]] 5v only parallel port<br />
* [[Flyswatter]]- USB<br />
* [http://docs.blackfin.uclinux.org/doku.php?id=hw:jtag:gnice gnICE] - USB w/full schematics<br />
* [http://www.section5.ch/icebear ICEbear JTAG] - USB<br />
* [http://www.renaelectronics.com/2007Fall/product_x_cable.htm JTAG Blue] - Parallel Port<br />
* http://wiki.openwrt.org/JTAG_Cables<br />
* http://hri.sourceforge.net/tools/ - Macraigor compatible wiggler<br />
* http://www.sparkfun.com/shop/index.php?shop=1&cart=201362&cat=74&<br />
* http://www.ocdemon.net/hwproducts.htm - $150-$1800 par,usb,serial,ethernet<br />
* http://www.dlpdesign.com/usb/2232m.shtml - USB module<br />
* http://www.corelis.com/products/index.htm - Emulators, Testing and Programming<br />
* http://www.amontec.com/jtagkey.shtml - USB<br />
* http://www.sparkfun.com/commerce/product_info.php?products_id=7834 - USB<br />
* http://www.ronetix.at/peedi.html - JTAG/BDM Emulator and Flash Programmer<br />
* http://www.mentor.com/products/embedded_software/majic-jtag-probe/ - JTAG Emulator, Flash Programmer, Hardware Bring-up<br />
<br />
=== Tools ===<br />
* [[JTAG_Finder]]<br />
* [[UsingJtagTools]]<br />
* http://openwince.sourceforge.net/jtag/<br />
* http://fjtag.sourceforge.net/<br />
* http://jtagtools.sourceforge.net/<br />
* http://www.lart.tudelft.nl/projects/jtag/jflash-linux.tar.gz<br />
* http://lapwww.epfl.ch/dev/arm/jelie/index.php<br />
* http://cvs.arm.linux.org.uk/cgi/viewcvs.cgi/jtag/<br />
* http://jtager.sourceforge.net/<br />
* http://openocd.berlios.de/web/<br />
* http://urjtag.org/<br />
<br />
[[Category:Development Tools]]</div>Vapierhttps://elinux.org/index.php?title=Porting_DirectFB&diff=10740Porting DirectFB2009-04-12T09:01:18Z<p>Vapier: merge a few fixes from duplicate Port_Direct_FB page</p>
<hr />
<div>== DirectFB porting to RTS7751R2D (SH-4/SM501) platform ==<br />
=== Development Environment ===<br />
==== SH-4 target platform environment ====<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" align="center"<br />
|! style="background:#d0a0a0;"|'''Item'''<br />
! style="background:#d0a0a0;"|'''Element'''<br />
! style="background:#d0a0a0;"|'''Resources'''<br />
|-<br />
|rowspan="2"|Hardware|| Renesas `RTS7751R2D` (Renesas SH-4 processor board)||rowspan="2"|[[RTS7751R2D Handling Manual]]<br />
|-<br />
| Silicon Motion Inc SM501 (Renesas platform on board graphics)<br />
|-<br />
|rowspan="7"|Software|| kernel = CE-LINUX-2.4.20||rowspan="2"|[[Tool Chains]]<br />
|-<br />
| loader = SH-LILO<br />
|-<br />
| [[DirectFB]] = DirectFB-0.9.20 ||http://www.directfb.org/download/DirectFB/DirectFB-0.9.20.tar.gz<br />
|-<br />
| freetype = freetype-2.1.3 || http://heanet.dl.sourceforge.net/sourceforge/freetype/freetype-2.1.3.tar.gz<br />
|-<br />
| libjpeg = jpeg-6b ||ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz<br />
|-<br />
| libpng = png-1.2.2 || http://keihanna.dl.sourceforge.net/sourceforge/libpng/libpng-1.2.2.tar.gz<br />
|-<br />
| zlib = zlib-1.1.4 || http://www.zlib.net/zlib-1.1.4.tar.gz<br />
|}<br />
<br />
<br />
=== x86 host machine environment ===<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" align="center"<br />
|! style="background:#d0a0a0;"|'''Item'''<br />
! style="background:#d0a0a0;"|'''Element'''<br />
! style="background:#d0a0a0;"|'''Resources'''<br />
|-<br />
|OS|| Linux ( Redhat 7.3 ) ||[http://ftp.redhat.com/pub/redhat/linux/7.3/]<br />
|-<br />
|host compiler || gcc 2.9.6 ||[http://www.gnu.org/software/gcc/]<br />
|-<br />
|cross compiler || gcc 3.2.3 ( CELF sh-4 compiler posted by Lineo Solutions )||[[Tool Chains]]<br />
|}<br />
<br />
== Install DirectFB ==<br />
=== Prepare libraries used in DirectFB ===<br />
<br />
* Extract each source code<br />
* Set environment variables for cross compile<br />
<br />
<pre><br />
CC = /usr/local/bin/sh4-linux-gcc <br />
CPP = /usr/local/bin/sh4-linux-cpp <br />
CXX = /usr/local/bin/sh4-linux-g++ <br />
</pre><br />
<br />
* create libjpeg<br />
<pre><br />
modify configure file for cross compile<br />
line 548 : change "gcc" to "sh4-linux-gcc"<br />
<br />
# ./configure --enable-shared<br />
# make<br />
# cp .libs/libjpeg.so* /usr/local/sh4-linux/lib<br />
</pre><br />
<br />
* create zlib<br />
<pre><br />
# ./configure --shared<br />
modify Makefile for cross compile<br />
line 24 : LDSHARED=/usr/local/bin/sh4-linux-gcc -shared -Wl,-soname,libz.so.1<br />
line 28 : LIBS=libz.so.1.1.4<br />
# make<br />
# cp libz* /usr/local/sh4-linux/lib<br />
</pre><br />
<br />
* create libpng<br />
<pre><br />
# cp scripts/makefile.linux Makefile<br />
modify Makefile for cross compile<br />
line 11 : change "gcc" to "sh4-linux-gcc"<br />
# make<br />
# cp libpng12.so* /usr/local/sh4-linux/lib<br />
</pre><br />
<br />
* create freetype<br />
<pre><br />
# ./configure --host=sh4-linux<br />
# make <br />
# cp objs/.libs/libfreetype.so* /usr/local/sh4-linux/lib<br />
# cp -r include/* /usr/local/sh4-linux/include<br />
</pre><br />
<br />
* Cross Compile DirectFB for SH-4<br />
<pre><br />
adopt patch upon DirectFb source directory<br />
# gzip -d -c DirectFB-0.9.20-ftpath.patch.gz | patch -p0 <br />
# ./configure --host=sh4-linux \ <br />
# --disable-sdl \ <br />
# --with-ftpath=/usr/local/sh4-linux <br />
# --with-gfxdrivers=sm501 <br />
# make <br />
<br />
If error occurs modify interfaces/IDirectFBFont/Makefile<br />
line 86 : remove "-lfreetype"<br />
</pre><br />
<br />
* We use CELF SH-4 root_fs image posted by Lineo Solutions. <br />
* We expect this root_fs is already bootable. <br />
* We expect root_fs is mounted on /mnt. <br />
* We add /usr/local/lib?/usr/lib to /etc/ld.so.conf <br />
* Prepare directory for DirectFB installation <br />
<br />
<pre><br />
# mkdir /usr/lib<br />
# mkdir /usr/local/share<br />
# mkdir /usr/local/share/directfb-examples<br />
# mkdir /usr/local/lib/<br />
# mkdir /usr/local/lib/directfb-0.9.20<br />
# mkdir /usr/local/lib/directfb-0.9.20/gfxdrivers<br />
# mkdir /usr/local/lib/directfb-0.9.20/inputdrivers<br />
# mkdir /usr/local/lib/directfb-0.9.20/interfaces<br />
# mkdir /usr/local/lib/directfb-0.9.20/interfaces/IDirectFBFont<br />
# mkdir /usr/local/lib/directfb-0.9.20/interfaces/IDirectFBImageProvider<br />
# mkdir /usr/local/lib/directfb-0.9.20/interfaces/IDirectFBVideoProvider<br />
# mkdir /usr/local/lib/directfb-0.9.20/systems<br />
</pre><br />
<br />
* copy libjpeg<br />
<pre><br />
move to libjpeg's directory<br />
# cp .libs/libjpeg.so* /mnt/usr/lib<br />
</pre><br />
<br />
* copy zlib <br />
<pre><br />
move to zlib's directory<br />
# cp libz.so* /mnt/usr/lib<br />
</pre><br />
<br />
* copy libpng <br />
<pre><br />
move to libpng's directory<br />
# cp libpng12.so /mnt/usr/lib/libpng.so<br />
# cp libpng12.so.0 /mnt/usr/lib/libpng.so.0<br />
# cp libpng12.so.0.1.2.2 /mnt/usr/lib/libpng.so.0.1.2.2<br />
</pre><br />
<br />
* copy freetype<br />
<pre><br />
move to freetype's directory<br />
# cp objs/.libs/libfreetype.so* /mnt/usr/lib<br />
</pre><br />
<br />
* copy DirectFB<br />
<pre><br />
move to DirectFB's directory<br />
# cp src/.libs/libdirectfb.so /mnt/usr/lib<br />
# cp src/.libs/libdirectfb-0.9.so* /mnt/usr/lib<br />
# cp gfxdrivers/sm501/.libs/libdirectfb_sm501.so /mnt/usr/local/lib/directfb-0.9.20/gfxdrivers<br />
# cp inputdrivers/joystick/.libs/libdirectfb_joystick.so /mnt/usr/local/lib/directfb-0.9.20/inputdrivers<br />
# cp inputdrivers/keyboard/.libs/libdirectfb_keyboard.so /mnt/usr/local/lib/directfb-0.9.20/inputdrivers<br />
# cp inputdrivers/ps2mouse/.libs/libdirectfb_ps2mouse.so /mnt/usr/local/lib/directfb-0.9.20/inputdrivers<br />
# cp inputdrivers/serialmouse/.libs/libdirectfb_serialmouse.so /mnt/usr/local/lib/directfb-0.9.20/inputdrivers<br />
# cp inputdrivers/sonypi/.libs/libdirectfb_sonypi.so /mnt/usr/local/lib/directfb-0.9.20/inputdrivers<br />
# cp interfaces/IDirectFBFont/.libs/libidirectfbfont_*.so /mnt/usr/local/lib/directfb-0.9.20/interfaces/IDirectFBFont<br />
# cp interfaces/IDirectFBImageProvider/.libs/libidirectfbimageprovider_*.so /mnt/usr/local/lib/directfb-0.9.20/interfaces/IDirectFBImageProvider<br />
# cp interfaces/IDirectFBVideoProvider/.libs/libidirectfbvideoprovider_*.so /mnt/usr/local/lib/directfb-0.9.20/interfaces/IDirectFBVideoProvider<br />
</pre><br />
<br />
=== Prepare Demo software ===<br />
<br />
Through previous steps, you have installed DirectFB to SH-4 Linux environment. To confirm everything created and installed properly use DirectFB demo program. You can download these demo program from DirectFB project website, that name is "DirectFB-examples". We used version 0.9.18. You can download from following Web site.<br />
<br />
[http://www.directfb.org/download/DirectFB/DirectFB-examples-0.9.18.tar.gz DirectFB-examples]<br />
<br />
As we faced some problem compiling these demo program for SH-4 Linux, we installed to x86 Linux first, then retarget to SH-4 Linux using following step.<br />
<br />
<pre><br />
Modify Makefile in src directry as<br />
"CC = gcc" to "CC = sh4-linux-gcc" <br />
"LIBADDS = -L/usr/local/lib -ldirectfb -lpthread -ldl" to <br />
"LIBADDS = -L/usr/local/sh4-linux/lib -ldirectfb -lpthread -ldl" <br />
Adopt same modification to each Makefile in src/df_knuckles?src/df_neo?src/spacedream<br />
</pre><br />
Do make in src directory ( If you do make at the upper directry, it seems not works correctly )<br />
<br />
=== Install Demo program ===<br />
<br />
Now demo program binary images was generated in src directory, you can copy manually these binary to target root_fs's your preferred location. Then copy all data file located under data directory to /usr/local/share/directfb-examples It seems you do not maintain/modift these file (just copy) except Makefile.<br />
<br />
=== Benchmark program ===<br />
<br />
Demo program named df_dok is DirectFB benchmark. If you run this without any options, it automatically runs set of benchmark program using graphics acceleration capability, and display result as graph. We use this benchmark score to tune DirectFB library for SM501.<br />
<br />
=== Cross compiling ===<br />
<br />
Like other Linux application program, DirectFB is designed to compile only on x86 Linux. We struggled this time to compile DirectFB for SH-4 Linux and finally we success this cross porting. However we think this is a kind of handwork way. When you try to run demo program on non-x86 Linux, x86 reference looks mandatory. I suggest you start DirectFB implementation from x86 Linux.<br />
<br />
== Writing DirectFB driver ==<br />
=== Graphics driver detection procedure ===<br />
<br />
Graphics chip drivers are located under /usr/local/lib/directfb-0.9.20/gfxdrivers There is no special installation procedure to add your own driver. DirectFB checks all drivers in driver_probe routine. When DirectFB detect correct driver in this process, DirectFB enables this driver. If driver does not works then move to next driver check, if all drivers does not much, DirectFB runs software mode without dedicated graphics driver. We have tentatively modified this process force to use SM501 driver.<br />
<br />
=== Enabling hardware graphics acceleration capability ===<br />
<br />
Drawing routine set command parameters to use 2D acceleration capability. Graphic driver returns TRUE or FALSE as return-value. If FALSE returned, DirectFB thinks hardware acceleration does not built-in, and use whole software drawing. Not all drawing routine has this acceleration detection mechanism, it is sure to define in `CheckState` routine. You can write your own driver as you like except command parameters and return value.<br />
<br />
== SM501 driver development ==<br />
=== reference driver ===<br />
<br />
We use i810 graphics driver as a reference, because it is small and looks easy to implement. Finally we need to refer other drivers because i810 has limited numbers of draw routine. If you want to support full drawing capabilities, Matrox driver may be better reference.<br />
<br />
=== Drawing API prepared for SM501 ===<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" align="center"<br />
! style="background:#d0a0a0;"|'''API'''<br />
! style="background:#d0a0a0;"|'''Operations'''<br />
|-<br />
|`sm501_set_src`||Set source address for BLIT operation. You need to assign VRAM physical address to source address.<br />
|-<br />
|`sm501_set_dest`||Set destination physical address and color depth for BLIT and drawing operation.<br />
|-<br />
|`sm501_set_colorkey`||colorkey setting, it defines transparent color for colorkeyed BLIT operation. Color compare regiser is used in SM501 to enable this operation. You can define transparent color to the SM501 color compare register, then SM501 does not transfer this color when doing BLIT operation. So it looks transparent.<br />
|-<br />
|`sm501_set_color`||Define drawing color setting<br />
|-<br />
|`sm501_set_clip`||Save clipping coordinates value to the structure, and set SM501 clipping register as well<br />
|-<br />
|`sm501CheckState`||This bit returns hardware acceleration capability. You need to refer each graphics spec, and you also care for color format that graphics supports<br />
|-<br />
|`sm501SetState`||Do pre-process for acceleration<br />
|-<br />
|`sm501FillRectangle`||Do fill rectangle, using SM501 2D drawing engine<br />
|-<br />
|`sm501DrawRectangle`||Draw rectangles. SM501 does not have rectangle drawing capability, so draw four lines to draw rectangle in this driver<br />
|-<br />
|`sm501Blit`||Do BLIT operation, using SM501 2D drawing engine<br />
|-<br />
|`sm501StretchBlit`||Do Stretch BLIT To avoid SM501 2D engine stretch function limitation, we use CSC (color space conversion) function instead. Colorkeyed stretch BLIT can not be support in this driver.<br />
|-<br />
|`sm501DrawLine`||Draw line, using SM501 2D drawing engine. Use shortstroke command for simple vertical / holizontal line,and use line command for other kind of line.<br />
|-<br />
|`sm501fill_tri`||Draw triangle with filling inside. As SM501 does not have hardware triangle drawing capability,we draw triangle by software. However we can use horizontal line draw capability in SM501, so seems to achieved a little better performance than all software drawing.<br />
|-<br />
|`sm501FillTriangle`||Fill triangle, actual operation execute in subroutine sm501fill_tri<br />
|-<br />
|`driver_get_abi_version`||Returns version information<br />
|-<br />
|`driver_probe`||This should return check result of expected graphics chip is exist or not. At this moment, this driver retunes always TRUE (=SM501 exist)<br />
|-<br />
|`driver_get_info`||Returns driver's information<br />
|-<br />
|`sm501_release_resource`||Do close operation<br />
|-<br />
|`driver_init_driver`||Initialize SM501 2D engine and create function table<br />
|-<br />
|`driver_init_device`||Initialize device structure<br />
|-<br />
|`driver_close_device`||Do nothing at this moment<br />
|-<br />
|`driver_close_driver`||Do nothing at this moment<br />
|}<br />
<br />
<br />
== DirectFB porting notes ==<br />
<br />
DirectFB requires display resolution capability built in frame buffer driver.<br />
So initially we modify SM501 generic frame buffer driver to support resolution<br />
and color depth setting. We did not care for pixel_clock, left/right margin and<br />
vertical/horizontal sync, because DirectFB does not works when frame buffer<br />
drivers return FALSE to these parameter. It looks no problem using without<br />
these parameters.<br />
<br />
Initially we modify reference gfxdriver (=i810) source code so that SH-4 gcc <br />
compiler can compile properly. Actually we maintain filename, display character<br />
and source code comment to fit SM501. And commented out driver code that operate<br />
2D graphics engine. After you compile SM501 driver, copy it to the proper location<br />
so that DirectFB can load this new driver. If DirectFB boot message does not comes<br />
driver location missing nor driver_probe process returns error.<br />
<br />
Then merge 2D engine sample program that works. In SM501 initialization call<br />
2D engine initialization and modify simple graphics API like line. You need to<br />
activate bit in `CheckState`, that has hardware acceleration in SM501.<br />
Remove unused program in driver_init_driver, to eliminate unexpected initialization.<br />
<br />
Once SM501 hardware acceleration works, replace other drawing API.<br />
If SM501 command support DirectFB drawing API, just use SM501 command. If SM501<br />
does not support it, you need to find out alternative way to implement this API.<br />
If your reference driver does not support required API, you need to refer other<br />
graphics driver and you need to add this function by yourself.<br />
<br />
If you added new hardware drawing API, you need to enable bit in `CheckState`<br />
and need to maintain function table list. Due to the limitations of graphics<br />
controller if some hardware acceleration can not be used, you need to disable<br />
corresponded bit in `CheckState`. For example SM501 can not handle ARGB format.<br />
If BLIT source format does not much target format, SM501 can not use hardware <br />
BLIT capability. In such case you need to disable bit in `CheckState`.<br />
<br />
To achieve better performance, we modify to use /dev/mem access instead of<br />
usual ioctl call, that was originally used in reference driver. After we<br />
maintained to read/write 2D engine register directly use /dev/mem, drawing<br />
performance increased dramatically especially `FillRect` type simple parameter<br />
command.<br />
<br />
Finally we removed un-used function built in reference driver. For example i810 driver include UMA setting. PCI initialization does not need when SM501 connect to SH-4 using SH-BUS. So we remove these portion.<br />
<br />
=== Reference ===<br />
<br />
Unfortunately we can not find any useful information to DirectFB port to SH-4 Linux. So we do it using step-by-step way using printk(). For 2D acceleration portion, sample program and device document were helpful. But sometime it is difficult to understand actual drawing limitations. So x86 DirectFB is mandatory as a reference when you port DirectFB to the Linux runs on embedded CPU like SH-4.<br />
<br />
== Resources ==<br />
<br />
You can download original source, patches and pre-compiled DirectFB program for `RTS7751R2D` platform <br />
<br />
=== logs ===<br />
* DirectFB configure logs attachment:conf_log<br />
* DirectFB make logs attachment:make_log<br />
<br />
=== source archives ===<br />
* DirectFB [[Image:DirectFB-0.9.20.tar.gz]] (1277kB)<br />
* Freetype [[Image:freetype-2.1.3.tar.gz]] (1021kB)<br />
* libjpeg [[Image:jpegsrc.v6b.tar.gz]] (599kB)<br />
* libpng [[Image:libpng-1.2.2.tar.gz]] (488kB)<br />
* zlib [[Image:zlib-1.1.4.tar.gz]] (177kB)<br />
<br />
=== patches ===<br />
* DirectFB SM501 patches [[Image:DirectFB-0.9.20-sh4-sm501.patch.tar.gz]] (21kB)<br />
<br />
=== kernel, root_fs ===<br />
* CELF kernel attachment:celinux.tgz (42MB)<br />
* root_fs for `RTS7751R2D` platform attachment:rootfs.tgz (36MB)<br />
<br />
[[Category:DirectFB]]<br />
[[Category:Multimedia]]</div>Vapierhttps://elinux.org/index.php?title=UClinux_Shared_Library&diff=10739UClinux Shared Library2009-04-12T08:47:48Z<p>Vapier: reorganize page to put relevant stuff at top and push down "noise", and update with real/current information</p>
<hr />
<div>== Using Shared Library on uClinux ==<br />
<br />
Shared Library support is important for various cases. Especially if you are using uClinux with LGPL library, if there is no Shared Library support with your system, that means you get hit by GPL/LGPL license issue because LGPL library can only be linked by Shared Library (dynamic link) or the application source code needs to be provided to the customer (if the customer wants).<br />
<br />
There were various efforts for supporting Shared Library on uClinux so far. This page describes those efforts with corresponding information.<br />
<br />
=== Shared FLAT ===<br />
<br />
The Shared FLAT format follows the FLAT format in terms of being an extremely stripped down and lightweight format:<br />
* minimal file header (~48 bytes)<br />
* minimal relocation table<br />
* only sections actually needed at runtime are retained (.text/.data/etc...)<br />
<br />
However, these things come by sacrificing flexibility:<br />
* every shared library has a unique hardcoded ID numbers which must be managed manually<br />
* maximum of ~256 shared libs<br />
* no dynamic support (libdl -- dlopen/dlsym/dlclose/etc...)<br />
* maximum individual executable size of 8megs<br />
<br />
=== FDPIC ELF ===<br />
<br />
The FDPIC ELF format brings all the amenities of the standard ELF format as seen on Desktop Linux systems. The trade offs are mostly obvious:<br />
* all executable code must be Position Independent Code (PIC)<br />
* no limits on the number of shared libraries<br />
* linking and library lookup is natural (SONAMEs, search paths, etc...)<br />
* dynamic library/plugin support works (libdl -- dlopen/dlsym/dlclose/etc...)<br />
<br />
=== Kernel 2.6.x status ===<br />
<br />
There are two options with recent kernels:<br />
* Shared FLAT format (grep the kernel for CONFIG_BINFMT_SHARED_FLAT)<br />
* FDPIC ELF (originally the implemented for FR-V)<br />
<br />
Most no-mmu Linux architectures support Shared FLAT, but the FDPIC ELF format is gathering ports. Support will greatly depend on the exact kernel version you are using, so check the ''fs/Kconfig.binfmt'' file if you are unsure.<br />
<br />
=== Kernel 2.4.x status ===<br />
<br />
Shared libraries under uClinux mini-HOWTO: http://www.ucdot.org/article.pl?sid=03/11/25/1126257&mode=thread<br />
<br />
But ARM does not support it, see at bottom page: http://www.ucdot.org/article.pl?sid=03/07/24/1333235&mode=thread<br />
<br />
Another interesting topic: http://www.ucdot.org/article.pl?sid=03/10/21/2153216&mode=thread<br />
<br />
=== Ridge Run and SnapGear announcement ===<br />
<br />
[http://www.ridgerun.com/ Ridge Run] and [http://www.snapgear.com SnapGear] has announced that they implemented Shared Library on uClinux long time ago. <br />
<br />
For more information: http://linuxdevices.com/articles/AT3186625227.html<br />
<br />
Ridge Run approach uses ELF format file and Snap Gear approach uses FLAT file format.<br />
<br />
The FLAT File Format method is supported by all Linux targets that support running Linux without an MMU<br />
<br />
Ridge Run stopped their business at 2002 but they are now back. Their method is described at: http://www.ridgerun.com/XflatPages/CadenuxXFLATSharedLibraries<br />
<br />
When they stopped, some of their code was released under GPL because they had something to do with Texas Instruments. [[Monta Vista]] may have some more information on this but currently none has seen Ridge Run's Shared Library implementation code at the open source region.<br />
<br />
But after they are back to their business, the new Ridge Run has set up xflat as an open source project at http://www.xflat.org<br />
<br />
=== Credit ===<br />
<br />
This rough page was originally created by Shawn Kwon but most of the information were collected from comments of various people including Paul Mundt, Steve Bunch, Tim Bird, Greg Ungerer, Todd Fischer, Alan Carvalho de Assis at celinux-dev mailing list. All the credit should go to them.</div>Vapierhttps://elinux.org/index.php?title=Embedded_Linux_Distributions&diff=10738Embedded Linux Distributions2009-04-12T08:29:36Z<p>Vapier: add the Blackfin uClinux Distribution as a vendor distro and update the uClinux distro description</p>
<hr />
<div>== Introduction ==<br />
<br />
Besides the Linux kernel, one of the advantage of embedded Linux is the ability to leverage hundreds if not thousands of existing free and open source packages to easily and quickly add new features to devices. These packages range from graphical libraries, multimedia libraries, network libraries, cryptographic libraries, network servers, infrastructure software and more. However, integrating all these components together requires a relatively deep knowledge of the components. Hence, embedded-specific distributions and build systems have been created to ease this process.<br />
<br />
== Vendor distros ==<br />
* The [http://blackfin.uclinux.org/gf/project/uclinux-dist Blackfin uClinux Distribution] by [http://www.analog.com/blackfin Analog Devices] - a fork of the uClinux distribution for Blackfin processors<br />
* Embedded Alley - see http://www.embeddedalley.com/<br />
* [http://www.kaeilos.com KaeilOS embedded linux]<br />
* Lineo Solutions [http://www.lineo.co.jp/eng/products-services/products/ulinux.html uLinux]<br />
* [[MontaVista]] Linux - see http://www.mvista.com/products_services.php<br />
* [[RidgeRun]] Linux - see http://www.ridgerun.com/sdk.shtml<br />
* [[TimeSys]] LinuxLink - see http://www.timesys.com/products/index.htm<br />
* [http://wiki.ubuntu.com/MobileAndEmbedded Ubuntu Mobile]<br />
* Wind River - see http://www.windriver.com/products/linux/<br />
* [http://www.littlebluelinux.com/ Little Blue Linux] - MPC Data<br />
<br />
== Platforms ==<br />
* [[Android]]<br />
* Moblin<br />
* OpenMoko<br />
* Maemo<br />
* Access Linux Platform<br />
* LIMO<br />
<br />
== Other distros ==<br />
* Snapgear Embedded Linux Distribution - http://www.snapgear.org/<br />
* [[Open Wrt]] - http://openwrt.org/<br />
* Embedded Debian - http://www.emdebian.org/<br />
** Emdebian has made some significant progress the last few years, and has now reached an usable state. [http://www.emdebian.org/emdebian/flavours.html Two versions of Emdebian] are available : Emdebian Grip and Emdebian Crush.<br />
** Neil Williams gave a talk ''Emdebian 1.0 release, small and super small Debian'' at the FOSDEM 2009. A [http://free-electrons.com/pub/video/2009/fosdem/fosdem2009-williams-emdebian-1.0-release.ogv video] is available.<br />
* Embedded Gentoo - http://embedded.gentoo.org/<br />
<br />
=== Special purpose embedded Linux distributions ===<br />
* [http://flashlinux.org.uk/ Flash Linux] - a distribution specifically for USB keys and Live CDs<br />
* Eagle Linux - http://www.safedesksolutions.com/eaglelinux/<br />
** An embedded Linux distribution aimed at helping users learn Linux by creating bootable Linux images "virtually from scratch". Eagle Linux 2.3 is currently distributed as a concise, 26-page PDF documenting the creation of a minimalist, network-ready Linux image for bootable CDs, floppies, or flash drives. See description at: http://ct.enews.deviceforge.com/rd/cts?d=207-106-2-28-5560-8662-0-0-0-1<br />
* [http://www.uclinux.org/ uClinux] A distribution targeting (but not only) systems without Memory Management Unit. See also [[UClinux Shared Library]].<br />
<br />
== Configuration and Build systems ==<br />
* [[Open Embedded]] - System for building full embedded images from scratch<br />
* [http://www.buildroot.net buildroot]<br />
** Buildroot is a set of Makefiles and patches that makes it easy generate a cross-compilation toolchain and root filesystem for your target Linux system using the uClibc C library.<br />
* [http://www.pengutronix.de/software/ptxdist/index_en.html PTXdist]<br />
** Kconfig based build system developed by [http://www.pengutronix.de/index_en.html Pengutronix] <br />
** GPL licensed<br />
** [http://free-electrons.com/pub/video/2009/fosdem/fosdem2009-schwebel-ptxdist.ogv Video] of a talk given by PTXdist developer Peter Schwebel at [http://www.fosdem.org FOSDEM 2009]<br />
* [http://www.linuxfromscratch.org/ Linux From Scratch]<br />
* LTIB - Linux Target Image Builder (by Stuart Hughes of FreeScale) - see http://savannah.nongnu.org/projects/ltib<br />
** [http://www.bitshrine.org/celf_ltib_bof_v1.2.pdf Slides] and [http://free-electrons.com/pub/video/2008/ols/ols2008-stuart-hughes-ltib.ogg video] of a talk on LTIB at the Ottawa Linux Symposium 2008<br />
<br />
* [http://www.mvista.com/download/fetchdoc.php?docid=342 Building Embedded Userlands] - Presentation by Ned Miljevic & Klaas van Gend at the ELC 2008 which compares different configuration and build systems. [http://free-electrons.com/pub/video/2008/elce/elce2008-miljevic-van-gend-embedded-userlands.ogv Video] of the conference available.<br />
<br />
== Obsolete things ==<br />
<br />
* [[Qplus Target Builder]] - Target image builder from ETRI<br />
<br />
== Further reading ==<br />
<br />
* [[Embedded OS]] mentions a variety of embedded operating systems, including embedded Linux.<br />
<br />
[[Category:Linux]]</div>Vapierhttps://elinux.org/index.php?title=Hardware_Hacking&diff=10737Hardware Hacking2009-04-12T08:24:27Z<p>Vapier: link in Blackfin add on cards</p>
<hr />
<div>== Consumer Devices ==<br />
<br />
*Information about running Linux on devices that are or have been available to the general public. This includes both officially supported devices and project devices (or devices that unofficially run Linux).<br />
<br />
=== Project Devices ===<br />
<br />
*[[TCube Info|TCube]]<br />
*[[Mobile_Pro|Mobile Pro]]<br />
*[[Didj]] from LeapFrog<br />
*[[DCT 5000]]<br />
*[[Pixter]]<br />
*[[Pixter Multimedia]]<br />
*[[TvNow]]<br />
*[[ZipIt]]<br />
*[http://zipit2system.sf.net Zipit2] - the new Zipit with better hardware<br />
*[[JuiceBox]]<br />
*[[DHT-Walnut]]<br />
*[[FX3002]] watch from fossil.<br />
*[[Hisense]] - USDTV HDTV Tuner DB-2010 running Linux<br />
*[[enc28j60]] - single chip 10baseT ethernet with SPI interface<br />
*[[R8610_Based_WAP]] - tiny x86 compatible WAPs with internal 2.5" HD runs Linux<br />
*[[SMC WSKP100]] - A wifi Skype phone from SMC<br />
*[http://www.opentom.org OpenTom] - community project around GPS TomTom devices<br />
<br />
=== Supported Devices ===<br />
<br />
* [http://en.wikipedia.org/wiki/NSLU2 Linksys NSLU2]. See also http://www.nslu2-linux.org<br />
* [http://en.wikipedia.org/wiki/Linksys_WRT54G_series#WRT54GL Linksys WRT54GL]<br />
* [http://wiki.neurostechnology.com/index.php/Neuros_OSD Neuros OSD]<br />
* [http://en.wikipedia.org/wiki/N770 Nokia 770]<br />
* [http://en.wikipedia.org/wiki/N800 Nokia 800]<br />
* [http://en.wikipedia.org/wiki/Sharp_Zaurus Sharp Zaurus]<br />
* [[AML_Products|AML Handheld devices]]<br />
<br />
== Development Boards and Tools==<br />
<br />
*Information about development boards for embedded Linux<br />
<br />
=== [[JTAG]] ===<br />
* [[Flyswatter]]<br />
<br />
=== [[ARM_Processor|ARM]] ===<br />
*[[ARM_Integrator_Info|ARM Integrator]]<br />
*[[OSK]] - OMAP Starter Kit<br />
*GAO Engineering Inc. - http://www.gaoengineering.com<br />
* [[DaVinci]] DVEVM Evaluation module - http://www.spectrumdigital.com/<br />
* [[ITSY]]<br />
* [[LART Project]]<br />
* [[Hammer_Board]]<br />
* Simtec Electronics - http://www.simtec.co.uk/<br />
* Open AT91RM9200 Evaluation Board - http://wiki.emqbit.com/free-ecb-at91<br />
* [[BeagleBoard]]<br />
* [[Balloonboard]]<br />
* KB9202 - http://www.kwikbyte.com/KB9202.html<br />
* Luminary Micro's '''LM3S6965''' is an ARM Cortex M3 MCU. There is an inexpensive development board available for it called the '''LM3S6965 Ethernet Evaluation Kit''', which is available from [http://www.mouser.com/ Mouser] and others for around $69.00 USD.<br />
* [[TechnologicSystems]]<br />
<br />
=== [[AVR32_Processor|AVR32]] ===<br />
* [[ATNGW100]] Network Gateway Kit http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102<br />
<br />
=== [[Blackfin]] ===<br />
<br />
* [http://docs.blackfin.uclinux.org/doku.php?id=hw:boards ADI Boards]<br />
* [http://docs.blackfin.uclinux.org/doku.php?id=hw:cards Add on cards for ADI Boards]<br />
* [http://docs.blackfin.uclinux.org/doku.php?id=buy_stuff#other_hardware Everyone else]<br />
* [http://youtube.com/watch?v=fKyQOntPEFs Demo video]<br />
<br />
=== MIPS ===<br />
<br />
=== PowerPC ===<br />
* Walnut (405GP) - http://amcc.com/Embedded/Downloads/download.html?cat=1&family=2<br />
* Ebony (440GP) -<br />
* Kuro Box-HG (MPC4281) - http://www.kurobox.com/mwiki/index.php/Kurobox/Kurobox-HG_Main_Page<br />
* Efika5200 (MPC5200) - http://www.powerdeveloper.org/program/efika/accepted<br />
<br />
=== SH ===<br />
<br />
=== i386 and compatible ===<br />
<br />
== Miniclusters ==<br />
<br />
* Portable cluster hardware and related technologies for parallel computer tutorials, demonstrations, research. <br />
<br />
Here is a list of original projects.<br />
<br />
* See http://eri.ca.sandia.gov/eri/related_technologies.html<br />
* See http://www.linuxdevices.com/articles/AT2143783710.html<br />
* See http://www.coreboot.org/data/clusters/bento/index.html<br />
* See http://www.coreboot.org/data/clusters/dq/index.html<br />
* See http://coreboot.org<br />
<br />
=== Hardware Tools and Information ===<br />
* [[Sparkfun_Camera]] - Low cost cmos camera<br />
* [[Ez_Usb]] - 8051 based usb devices<br />
* [[Mini_LA]] - open source logic analyzer<br />
* [[NTSC_Bitbang]] - detailed concepts on NTSC<br />
* [[Lithium_Ion_Charger]] - Li-Ion battery charger design<br />
* [[Libertas SDIO]] - Marvell Libertas SDIO information<br />
* [[Nand_Flash256]] - common 256MB nand flash devices<br />
* [[Nor_vs_Nand]] - data comparisons between Nor and Nand Flash<br />
* [[TUSB2046B]] - four port usb chipset<br />
<br />
[[Category:Hardware Hacking| ]]</div>Vapierhttps://elinux.org/index.php?title=Blackfin&diff=10736Blackfin2009-04-12T08:23:05Z<p>Vapier: fill out "MMU" description with real information</p>
<hr />
<div>The Blackfin processor was designed by and is manufactured by Analog Devices ([[Board and Chip Vendors#A]]).<br />
Several boards that include a Blackfin processor are available ([[Hardware Hacking#Blackfin]]).<br />
<br />
All Blackfin processors include Debug/[[JTAG]] Interface for in-system debugging.<br />
<br />
Blackfin processors are fast enough to support real-time H.264 video encoding.<br />
<br />
The Blackfin processor documentation describes a Memory Management Unit (MMU), but this is not a MMU in the sense that most people expect: it has no Virtual Memory (VM) support. It does however provide all other aspects associated with your typical MMU on a variable page sized basis such as Memory Protection (read/write/execute) and caching. The documentation refers to these mappings as the Cacheability Protection Lookaside Buffer (CPLD) tables and are similar to TLBs in most other processor architectures.<br />
<br />
As such, all current Blackfin parts can only run Linux with MMU support turned off (what people have historically thought of as "uClinux").<br />
<br />
The processors also fully enforces privileged execution -- the classical user / supervisor permission split. The Linux kernel runs in supervisor mode where it has full access to the hardware while the Linux userspace runs in user mode and prevents tampering with hardware resources.<br />
<br />
== Further reading ==<br />
<br />
* the [http://docs.blackfin.uclinux.org/ Blackfin Linux wiki]<br />
* the [http://blackfin.uclinux.org/ Blackfin Open Source Koop]</div>Vapierhttps://elinux.org/index.php?title=Board_and_Chip_Vendors&diff=10735Board and Chip Vendors2009-04-12T08:12:04Z<p>Vapier: add a bunch of Blackfin vendors</p>
<hr />
<div>This page has a list of the companies or organizations that make processors or boards for <br />
embedded products. If you are looking for companies who sell Linux software or Linux-related services,<br />
see the [[Vendors]] page. If you are looking for companies who sell end-user products based on<br />
Linux, see [[Companies]]. If you are looking for information about specific development boards, see<br />
[http://elinux.org/Category:Development_Boards Category:Development Boards]<br />
<br />
== A ==<br />
* [http://www.amcc.com/Embedded/ AMCC] - Applied Micro Circuits Corporation<br />
** makes embedded PowerPC processors??<br />
* AMD<br />
** acquired ATI and now produces MIPS-based embedded processors (Xilleon series)<br />
** Also, used to make Geode chip<br />
* [http://www.analog.com Analog Devices] - [http://en.wikipedia.org/wiki/Analog_Devices Wikipedia entry]<br />
** ADI designs and manufactures the [http://www.analog.com/blackfin Blackfin processor], which has been in the mainline Linux kernel since 2.6.22 (May 2007).<br />
** There is a [http://blackfin.uclinux.org/ central open source site] with a dedicated [http://docs.blackfin.uclinux.org/ documentation wiki]<br />
** Many more Blackfin manufactures can be found in [http://docs.blackfin.uclinux.org/doku.php?id=buy_stuff#other_hardwares_and_providers that wiki] as well<br />
* [http://www.arm.com/ ARM] - [http://en.wikipedia.org/wiki/ARM_Holdings Wikipedia entry]<br />
** ARM designs ARM architecture processors, and license the technology to companies that actually make the chips<br />
* [http://www.armadeus.com Armadeus]<br />
** affordable ARM boards<br />
** Armadeus started as a community project <br />
* [http://www.atmel.com Atmel] - [http://en.wikipedia.org/wiki/Atmel Wikipedia entry]<br />
** Atmel makes [http://www.atmel.com/products/AT91/ AT91SAM 32-bit ARM-based Microcontrollers]<br />
** [http://www.linux4sam.org AT91 Linux gateway]<br />
<br />
== B ==<br />
* [http://www.bluetechnix.com/ Bluetechnix] makes tiny Blackfin modules to simplify custom board development<br />
* Broadcom - makes ARM chips for mobile phone market<br />
<br />
== C ==<br />
* [http://www.calao-systems.com/ CALAO Systems] sells tiny and cheap ARM based boards<br />
* [http://www.camsig.co.uk/ Cambridge Signal Processing] makes tiny Blackfin modules to simplify custom board development<br />
* [http://www.cdatas.com/ C Data Solutions] makes tiny Blackfin modules to simplify custom board development<br />
* [http://www.cirrus.com Cirrus Logic] - [http://en.wikipedia.org/wiki/Cirrus_Logic Wikipedia entry]<br />
** Cirrus Logic makes [http://www.cirrus.com/en/products/pro/techs/T7.html ep93xx and ep73xx 32-bit ARM-based Microcontrollers]<br />
<br />
== D ==<br />
* [http://dkc1.digikey.com/us/mkt/beagleboard.html DigiKey] sells the OMAP3 based [http://www.beagleboard.org beagleboard] <br />
<br />
== E ==<br />
* [http://www.eflagtech.com/ EFlag Tech] does custom Blackfin platform designs (software and hardware)<br />
<br />
== F ==<br />
* [http://www.freescale.com/ Freescale Semiconductor] - [http://en.wikipedia.org/wiki/Freescale_Semiconductor Wikipedia entry]<br />
** Freescale makes the MX31 ARM11-based processor (and associated development boards), among others.<br />
** Freescale makes several PPC-based processors (and associated development boards) as well.<br />
<br />
== G ==<br />
* [http://www.gumstix.com/ Gumstix] sells various very small processor and add-on boards. Especially interesting for robotics related projects.<br />
<br />
== H ==<br />
* [http://www.hhcn.com/english/enindex.html Hua Heng Tech] does custom Blackfin platform designs (software and hardware)<br />
* [http://www.hvsistemas.com/ HV Sistemas S.L.] makes tiny Blackfin modules to simplify custom board development<br />
<br />
== I ==<br />
* [http://www.ibm.com/ IBM] - [http://en.wikipedia.org/wiki/IBM Wikipedia entry]<br />
** Makes embedded PowerPC processor chips, such as the PPC 440 line<br />
<br />
== K ==<br />
* [http://www.kwikbyte.com/ KwikByte] sells full-featured ARM based boards:<br />
** Such as the: [http://www.kwikbyte.com/KB9202.html KB9202], [http://www.kwikbyte.com/KB9260.html KB9260] and [http://www.kwikbyte.com/KBAT9261.html KBAT9261]<br />
<br />
== M ==<br />
* [http://www.marvell.com Marvell] sells a lot of ARM chips.<br />
** One of the most interesting ones is probably the [[Marvell 88W8618]] which is used in the [[Freecom MusicPal]].<br />
<br />
== N ==<br />
* NEC - makes ARM chips, used to make lots of MIPS chips<br />
<br />
== Q ==<br />
* [http://www.qualcomm.com Qualcomm] - makes multicore ARM [http://www.qctconnect.com/products/mobile-processors.html MSM] products that support Linux<br />
** Their [http://www.qctconnect.com/products/snapdragon.html Snapdragon] platform provides a 1GHz ARM core and advanced DSP.<br />
<br />
== R ==<br />
* [http://www.renesas.com/ Renesas Technology] - [http://en.wikipedia.org/wiki/Renesas_Technology Wikipedia entry]<br />
** Renesas makes the SuperH, M32R, and H8 RISC CPUs, the RX CISC CPUs, and others.<br />
<br />
== S ==<br />
* Samsung - makes ARM processors<br />
* [http://www.sirf.com SiRF] - Makes besides GPS products also ARM based SoC for location aware devices, like the [http://sirf.com/products/multifunction2.html ARM9 based Atlas III (codename) at4x0a] and the [http://sirf.com/products/multifunction3.html ARM11 based SiRFPrima].<br />
* [http://www.sunplusmm.com/ Sunplus] is a company specialising in chips for multimedia and mobile applications. One of their interesting chips is the [[Sunplus SPMP3050A]] which is used in MP4 players.<br />
* [http://www.surveyor.com/ Surveyor Corporation] makes Blackfin based robot modules for academics, hobbyists, and professionals<br />
<br />
== T ==<br />
* [http://www.ti.com/ Texas Instruments] - [http://en.wikipedia.org/wiki/Texas_Instruments Wikipedia entry]<br />
** Texas Instruments makes the MSP430 MCUs, TMS320 C2000/C5000/C6000 DSPs, [http://linux.davincidsp.com DaVinci]/[http://linux.omap.com OMAP] ARM+DSP-based processors, and others.<br />
<br />
[[Category:Hardware]]</div>Vapierhttps://elinux.org/index.php?title=The_Art_of_Debugging_with_GDB,_DDD,_and_Eclipse&diff=10734The Art of Debugging with GDB, DDD, and Eclipse2009-04-12T07:59:29Z<p>Vapier: link in the publisher's webpage for this book</p>
<hr />
<div>== The Art of Debugging with GDB, DDD, and Eclipse ==<br />
<br />
''' [http://oreilly.com/catalog/9781593271749/ Norman Matloff, Peter Jay Salzman, No Starch Press, ISBN-13: 978-1593271749] '''<br />
<br />
Description from [[http://www.amazon.com/dp/1593271743 Amazon]]:<br />
<br />
The Art of Debugging illustrates the use three of the most popular debugging tools on Linux/Unix platforms: [[GDB]], [[DDD]], and [[Eclipse]]. The text-command based GDB (the GNU Project Debugger) is included with most distributions. DDD is a popular GUI front end for GDB, while Eclipse provides a complete integrated development environment.<br />
<br />
In addition to offering specific advice for debugging with each tool, authors Norm Matloff and Pete Salzman cover general strategies for improving the process of finding and fixing coding errors, including how to:<br />
* Inspect variables and data structures<br />
* Understand segmentation faults and core dumps<br />
* Know why your program crashes or throws exceptions<br />
* Use features like catchpoints, convenience variables, and artificial arrays<br />
* Avoid common debugging pitfalls<br />
<br />
Real world examples of coding errors help to clarify the authors' guiding principles, and coverage of complex topics like thread, client-server, GUI, and parallel programming debugging will make you even more proficient. You'll also learn how to prevent errors in the first place with text editors, compilers, error reporting, and static code checkers.<br />
<br />
<br />
<br />
==== Comments ====<br />
<br />
[[User:Kaa-ching]] says:<br />
Matloff does a great job at introducing a great piece of debuggging software, present why and how you want to use it and goes into details about almost anything you can do with GDB or with the graphical front-ends DDD or Eclipse.<br />
The book is very readable and easy to follow and contains many great examples. This book really is worth your money.<br />
<br />
[[Category:Books]]</div>Vapierhttps://elinux.org/index.php?title=Essential_Linux_Device_Drivers&diff=10733Essential Linux Device Drivers2009-04-12T07:58:39Z<p>Vapier: link in the book's homepage</p>
<hr />
<div>== Essential Linux Device Drivers ==<br />
<br />
''' Sreekrishnan Venkateswaran, Prentice Hall Open Source Software Development Series, ISBN-10: 0132396556 <br />
ISBN-13: 9780132396554, 744 pages '''<br />
<br />
This book does a very decent attempt at describing everything you need to know about Linux driver development. <br />
<br />
From the Amazon website:<br />
* Addresses drivers discussed in no other book, including drivers for I2C, video, sound, PCMCIA, and different types of flash memory<br />
* Demystifies essential kernel services and facilities, including kernel threads and helper interfaces<br />
* Teaches polling, asynchronous notification, and I/O control<br />
* Introduces the Inter-Integrated Circuit Protocol for embedded Linux drivers<br />
* Covers multimedia device drivers using the Linux-Video subsystem and Linux-Audio framework<br />
* Shows how Linux implements support for wireless technologies such as Bluetooth, Infrared, WiFi, and cellular networking<br />
* Describes the entire driver development lifecycle, through debugging and maintenance<br />
* Includes reference appendixes covering Linux assembly, BIOS calls, and Seq files<br />
<br />
Be sure to also visit [http://elinuxdd.com/ the book's homepage] as it contains misc updates, errata, source code, etc...<br />
<br />
==== User comments ====<br />
Comment from Alan Cox “Probably the most wide ranging and complete Linux device driver book I’ve read.”.<br />
<br />
Comment from [[Kaa-ching]]: I really liked the book. It is up-to-date (at least early 2008 it was :-) ) and comprehensive. <br />
<br />
Comment from [[ThomasPetazzoni]] : This book is a nice addition to the traditional Linux Device Drivers. Not only because it is more up-to-date, but also because it covers a wider range of drivers. However, reading Linux Device Drivers first is probably recommended. In the end, I think both books are very complementary.<br />
<br />
See also http://vig.pearsoned.co.uk/catalog/academic/product/0,1144,0132396556,00.html<br />
<br />
[[Category:Books]]</div>Vapierhttps://elinux.org/index.php?title=Building_Embedded_Linux_Systems&diff=10732Building Embedded Linux Systems2009-04-12T07:56:35Z<p>Vapier: link in the publisher's webpage for this book</p>
<hr />
<div>== Building Embedded Linux Systems, 2nd Edition ==<br />
<br />
''' [http://oreilly.com/catalog/9780596529680/ Karim Yaghmour, Jon Masters, Gilad Ben-Yossef, Philippe Gerum, O'Reilly Media, Inc., ISBN-13: 978-0596529680] '''<br />
<br />
This second edition (mainly done by Jon Masters) gives you the basics of building embedded Linux systems, along with the configuration, setup, and use of several open source and free software packages in common use. The book also looks at the strengths and weaknesses of using Linux in an embedded system, plus a discussion of licensing issues, and an introduction to real-time, with a discussion of real-time options for Linux.<br />
<br />
This book features:<br />
* What the different embedded Linux distributions (both open and commercial) are and why there are so many<br />
* How to build your own GNU development toolchain<br />
* How to Select, configure, build, and deploy a kernel on an embedded system<br />
* How to create a target root filesystem<br />
* Information on setting up and using flash devices and flash file systems<br />
* Install and configuring a bootloader for the target<br />
* Cross-compiling a slew of utilities and packages<br />
* Debugging your embedded system using gdb, kgdb, strace and other techniques<br />
* a discussion on the RTLinux (microkernel + Linux) approach<br />
* a discussion on the Linux Real Time patch<br />
<br />
'''Make sure to get the second edition - the first edition (from 2003) is extremely outdated!'''<br />
<br />
[[Category:Books]]</div>Vapierhttps://elinux.org/index.php?title=Embedded_Linux_Primer&diff=10731Embedded Linux Primer2009-04-12T07:55:20Z<p>Vapier: link in the book's homepage</p>
<hr />
<div>== Embedded Linux Primer, a practical, real-world approach ==<br />
<br />
''' Christopher Hallinan, Prentice Hall PTR, ISBN-13: 978-0131679849 '''<br />
<br />
Hallinan begins by touring a typical Linux-based embedded system, introducing key concepts and components, and calling attention to differences between Linux and traditional embedded environments. Writing from the embedded developer’s viewpoint, he addresses issues ranging from kernel building and initialization to bootloaders, device drivers to file systems.<br />
<br />
This book covers the increasingly popular BusyBox utilities; presents a step-by-step walkthrough of porting Linux to custom boards; and introduces real-time configuration via CONFIG_RT--one of today’s most exciting developments in embedded Linux. You’ll find especially detailed coverage of using development tools to analyze and debug embedded systems--including the art of kernel debugging.<br />
<br />
* Understand the details of the Linux kernel initialization process<br />
* Learn about the special role of bootloaders in embedded Linux systems, with specific emphasis on U-Boot<br />
* Use embedded Linux file systems, including JFFS2--with detailed guidelines for building Flash-resident file system images<br />
* Understand the Memory Technology Devices subsystem for flash (and other) memory devices<br />
* Master gdb, KGDB, and hardware JTAG debugging<br />
* Learn many tips and techniques for debugging within the Linux kernel<br />
* Maximize your productivity in cross-development environments<br />
* Prepare your entire development environment, including TFTP, DHCP, and NFS target servers<br />
* Configure, build, and initialize BusyBox to support your unique requirements<br />
<br />
There is a reason this book has been the #1 book on [http://www.amazon.com/gp/bestsellers/books/3730 Amazon embedded systems] for more than two years now!<br />
<br />
Be sure to also visit [http://www.embeddedlinuxprimer.com/ the book's homepage].<br />
<br />
[[Category:Books]]</div>Vapierhttps://elinux.org/index.php?title=Embedded_Linux_Primer&diff=10729Embedded Linux Primer2009-04-12T07:53:34Z<p>Vapier: Embedded linux primer moved to Embedded Linux Primer: fix caps in title</p>
<hr />
<div>== Embedded Linux Primer, a practical, real-world approach ==<br />
<br />
''' Christopher Hallinan, Prentice Hall PTR, ISBN-13: 978-0131679849 '''<br />
<br />
Hallinan begins by touring a typical Linux-based embedded system, introducing key concepts and components, and calling attention to differences between Linux and traditional embedded environments. Writing from the embedded developer’s viewpoint, he addresses issues ranging from kernel building and initialization to bootloaders, device drivers to file systems.<br />
<br />
This book covers the increasingly popular BusyBox utilities; presents a step-by-step walkthrough of porting Linux to custom boards; and introduces real-time configuration via CONFIG_RT--one of today’s most exciting developments in embedded Linux. You’ll find especially detailed coverage of using development tools to analyze and debug embedded systems--including the art of kernel debugging.<br />
<br />
* Understand the details of the Linux kernel initialization process<br />
* Learn about the special role of bootloaders in embedded Linux systems, with specific emphasis on U-Boot<br />
* Use embedded Linux file systems, including JFFS2--with detailed guidelines for building Flash-resident file system images<br />
* Understand the Memory Technology Devices subsystem for flash (and other) memory devices<br />
* Master gdb, KGDB, and hardware JTAG debugging<br />
* Learn many tips and techniques for debugging within the Linux kernel<br />
* Maximize your productivity in cross-development environments<br />
* Prepare your entire development environment, including TFTP, DHCP, and NFS target servers<br />
* Configure, build, and initialize BusyBox to support your unique requirements<br />
<br />
There is a reason this book has been the #1 book on [http://www.amazon.com/gp/bestsellers/books/3730 Amazon embedded systems] for more than two years now!<br />
<br />
[[Category:Books]]</div>Vapierhttps://elinux.org/index.php?title=Embedded_linux_primer&diff=10730Embedded linux primer2009-04-12T07:53:34Z<p>Vapier: Embedded linux primer moved to Embedded Linux Primer: fix caps in title</p>
<hr />
<div>#REDIRECT [[Embedded Linux Primer]]</div>Vapierhttps://elinux.org/index.php?title=ELC2009_Editor_Contest&diff=10722ELC2009 Editor Contest2009-04-11T00:11:23Z<p>Vapier: fix spurious line wrapping</p>
<hr />
<div>The ELC 2009 Editor Contest is a competition, with a prize for the winner, to see<br />
which attendee of ELC 2009, or member of the public, can make the "best" set of edits to the eLinux wiki.<br />
<br />
== Contest Phases ==<br />
The contest is being run in 3 phases:<br />
* '''Phase 1''': April 6 - During the eLinux wiki working BOF<br />
** Phase 1 is DONE! - Many valuable prizes (worth up to dollars) were handed out!<br />
<br />
* '''Phase 2''': April 6-8 - During ELC itself<br />
** Phase 2 is DONE! - Thomas Petazzoni won a Sony DSCT700 digital still camera, by producing a number of useful edits during the conference period.<br />
<br />
* '''Phase 3''': April 6 - May 15 - Following on to ELC<br />
** Phase 3 is STILL OPEN!<br />
<br />
Phases 1 and 2 were open to registered ELC attendees only.<br />
Phase 3 is open to the general public.<br />
<br />
== Simple Instructions ==<br />
* Create a user account on the eLinux.org wiki<br />
* Add or edit pages on this site.<br />
** See [[Volunteering]] for ideas.<br />
* CELF will decide which user has made the "best" set of edits, and will award a prize to the person making the edits.<br />
<br />
== Prizes ==<br />
=== Phase 1 prizes ===<br />
Come to the BOF tonight and see. Prizes range from T-shirts to chocolates.<br />
<br />
=== Phase 2 prize ===<br />
Sony DSCT700 Digital Still Camera<br />
<br />
This will be awarded at the ELC Social event at the Exploratorium, Wednesday evening.<br />
<br />
=== Phase 3 prizes ===<br />
The grand prize winner will receive, at their option:<br />
* A new Sony Playstation 3 game console<br />
''or''<br />
* $500 U.S.<br />
Up to 3 runner-up prizes will be awarded of $100 U.S.<br />
<br />
== Rules ==<br />
Here are the rules for the contest:<br />
* The contest runs from April 6, 2009 until May 15, 2009 (6 weeks from the start of the conference)<br />
* In order to receive credit for your entries, you must make them as a logged-in user. For phases 1 and 2, the user name on the account must be matchable to a registered attendee of the Embedded Linux Conference 2009. In case of phase 2 and 3, your e-mail address used to register for the conference will be used to notify you in case you are the winner of the contest. (In the case of phase 2, you can receive your prize at the social event if you are present.)<br />
* You may only add material which is allowed by copyright laws. That is, you may write new material or quote material that is copyrighted by someone else, as allowed by fair use. However, you may not copy verbatim materials from another source unless allowed to do so by an appropriate license.<br />
* Entries will by judged by examining the "Recent changes" log for the eLinux wiki, for the contest period. They will be judged by a panel consisting of members of the CE Linux Forum, with Tim Bird as the judging committee Chair.<br />
* The winner will be notified by e-mail no later than May 29, 2009. Delivery of the prize will be arranged with the award-winner at that time. The award-winner will also be announced on the wiki.<br />
<br />
== Judging Criteria ==<br />
The judges will evaluate the edits based on a number of criteria, including:<br />
* the number of edits and/or size of edits<br />
* the originality of the edits or additions<br />
* the quality of the edits, including:<br />
** whether the edits conform to accepted formatting for the wiki<br />
** whether the edits are grammatically and syntactically correct<br />
** ''how much useful information the edits contribute contribute for other embedded Linux developers''<br />
<br />
This last criteria ("usefulness") will dominate the evaluation.<br />
<br />
== Notes ==<br />
I know this is a wiki, but please don't edit this page to change the rules in your favor... :-)</div>Vapierhttps://elinux.org/index.php?title=Kernel_Debugging_Tips&diff=10456Kernel Debugging Tips2009-03-31T08:28:05Z<p>Vapier: add a tip for generating preprocessed (.i) output</p>
<hr />
<div>Here are some miscellaneous tips for debugging a kernel:<br />
<br />
== Using printks ==<br />
To add your own debug message to the kernel, you can place a "printk()" in the kernel code.<br />
<br />
These messages are logged to an internal buffer, and eventually displayed by the kernel,<br />
being emitted to whatever is the active console, at the time of display. Since the console<br />
is not initialized until part-way through the boot sequence, several messages build up in<br />
the log until the console is initialize, at which point all buffered messages are displayed<br />
at once.<br />
<br />
After the messages are displayed on the kernel console, they are left in the log buffer (which<br />
is a ring buffer), and they can be (and usually are) retrieved later by various commands.<br />
<br />
printk is a variable-argument function, just like printf. Note that there is no "printf()"<br />
function for the kernel. "printk()" is used to specifically remind kernel developers<br />
that the environment is different.<br />
<br />
printk can use many standard C-style printf format characters, but not all of them. See the<br />
kernel source for examples of what you can do.<br />
<br />
=== Log levels ===<br />
Each kernel message can be pre-pended with a tag indicating the importance of the message.<br />
The message tags are shown in the file include/linux/kernel.h. The available tags are:<br />
KERN_EMERG, KERN_ALERT, KERN_CRIT, KERN_WARNING, KERN_NOTICE, KERN_INFO, KERN_DEBUG.<br />
<br />
Note that these tags are defined as simple strings, with angle brackets and a number:<br />
#define KERN_INFO "<6>"<br />
<br />
You could place the tag onto front of the string without using the #define, but that is <br />
considered very bad form, and is discouraged.<br />
<br />
The way the tag is placed on the string is with C string concatenation:<br />
printk(KERN_DEBUG "This is a debug message\n");<br />
<br />
Note that there is no comma between the tag macro and the message string.<br />
<br />
=== Adding timing information ===<br />
Sometimes, it is useful to add timing information to the printk values, so you<br />
can see when a particular event occurred. The kernel includes an feature for doing<br />
this called printk times.<br />
<br />
See the help for CONFIG_PRINTK_TIMES in the file lib/Kconfig.debug for more information on<br />
this feature. This option is found on the "Kernel Hacking" menu when configuring the kernel.<br />
<br />
The timestamps which are inserted into the printk output consist of seconds and microseconds,<br />
as absolute values from the start of machine operation (or from the start of kernel timekeeping).<br />
<br />
There is also tool in the kernel source which will convert the timestamp values to relative<br />
values (so you can see the interval between events). This tools is called show_delta and is<br />
located in the kernel 'scripts' directory.<br />
<br />
See [[Printk Times]] for more information.<br />
<br />
=== Viewing log messages ===<br />
The <tt>klogd</tt> program will extract messages from the kernel log buffer, and send them to the system<br />
log (which winds up in /var/log/messages on most systems). This command runs in the background<br />
on most desktop or server systems, and continually transfers messages from the kernel log<br />
buffer to the system log.<br />
<br />
You can view the contents of the log buffer directly, using the <tt>dmesg</tt> command. Note that by<br />
default <tt>dmesg</tt> displays the messages from the buffer, but does not remove them. So this command<br />
can be run multiple times to view the kernel printk messages. See the dmesg man page for more things<br />
you can do with this tool.<br />
<br />
=== Controlling console output ===<br />
In order to have the kernel boot be less "noisy", or in order to boot more quickly, it is sometimes<br />
useful to control the amount of messages displayed to the console during boot. You can do this<br />
by setting the kernel log level at boot time via a kernel command line option. See the "loglevel="<br />
argument in <tt>Documentation/kernel-parameters.txt</tt>.<br />
<br />
You can turn off all messages using the kernel command line option "quiet".<br />
See [[Disable Console]] for information on how much time this save at boot up.<br />
<br />
Note that even if the log level is changed, or "quiet" is used, although the printk messages<br />
are not print to console, they are still entered into the log buffer, and they can still be<br />
extracted and displayed later using the <tt>dmesg</tt> command.<br />
<br />
=== Changing the size of the printk buffer ===<br />
The size of the buffer that printk writes to is referred to in the kernel source as the "log buffer".<br />
<br />
You can make the log buffer larger when you build the kernel.<br />
This is useful for when additional printk data (such as extra messages inserted<br />
for debugging) is produced by the kernel and it overflows the regular buffer.<br />
The log buffer is a ring buffer, so later messages will overwrite the earliest messages<br />
in the buffer if too much data is written before the log buffer is drained (by, e.g. klogd or dmesg)<br />
<br />
Step 1: Change the kernel log buffer size:<br />
<br />
On the General Setup menu, change "Kernel log buffer size" to a larger number.<br />
This corresponds to LOG_BUF_SHIFT, which is the power-of-two size of the log buffer.<br />
By default, this is 14, which yeilds a log buffer size of 16KB. Changing this to<br />
17 will yield a log buffer size of 128KB.<br />
<br />
Set the option, then re-build and install the kernel for booting on the target board.<br />
<br />
Step 2: Tell dmesg to retrieve the larger buffer:<br />
Even though the buffer is larger in the kernel, dmesg will still default to only<br />
reading 16K, unless told otherwise. To read the full buffer, use the '-s' option<br />
like so: "dmesg -s 128000"<br />
<br />
== Debugging early boot problems ==<br />
=== Accessing the printk buffer after a silent hang on boot ===<br />
Sometimes, if the kernel hangs early in the boot process, you get no<br />
messages on the console before the hang. However, there may still<br />
be messages in the printk buffer, which can give you an idea of<br />
where the problem is.<br />
<br />
The kernel starts putting messages into the printk buffer as soon<br />
as it starts. They stay buffered there until the console code<br />
has a chance to initialize the console device (often the serial<br />
port for embedded devices). Eve though these messages<br />
are no printed before the hang, it is still possible in some circumstances<br />
to dump the printk buffer and see the messages.<br />
<br />
Quinn Jensen writes:<br />
<br />
Something I've found handy when the console is<br />
silent is to dump the printk buffer from the boot<br />
loader. To do it you have to know how your boot<br />
loader maps memory compared to the kernel.<br />
<br />
==== Redboot example on a Freescale ADS board ====<br />
Quinn says: Here's what I do with Redboot on i.MX31:<br />
<br />
fgrep printk_buf System.map<br />
<br />
this shows the linked address of the printk_buf, e.g.:<br />
<br />
c02338f0 b printk_buf.16194<br />
<br />
The address "c02338f0" is in kernel virtual, which,<br />
in the case of i.MX31 ADS, redboot will have mapped<br />
to 0x802338f0. So, after resetting the target board,<br />
but without letting it try to boot again, at the redboot<br />
prompt,<br />
<br />
dump -b 0x802338f0 -l 10000<br />
<br />
And you see the printk buffer that never got flushed<br />
to the UART. Knowing what's there can be '''very'''<br />
useful in debugging your console.<br />
<br />
==== U-boot example on an OMAP OSK board ====<br />
Tim Bird tried these steps and they worked:<br />
<br />
grep __log_buf System.map<br />
<br />
or<br />
<br />
grep __log_buf /proc/kallsyms<br />
<br />
These show:<br />
<br />
c0352d88 B __log_buf<br />
<br />
In the case of the OSK, this address maps to<br />
0x10352d88. So I reset the target board and use the following:<br />
<br />
OMAP5912 OSK # md 10352d88<br />
10352d88: 4c3e353c 78756e69 72657620 6e6f6973 <5>Linux version<br />
10352d98: 362e3220 2e32322e 612d3631 6e5f706c 2.6.22.16-alp_n<br />
10352da8: 7428206c 64726962 6d697440 6b736564 l (tbird@timdesk<br />
10352db8: 2e6d612e 796e6f73 6d6f632e 67282029 .am.sony.com) (g<br />
10352dc8: 76206363 69737265 33206e6f 342e342e cc version 3.4.4<br />
10352dd8: 34232029 45525020 54504d45 65755420 ) #4 PREEMPT Tue<br />
...<br />
<br />
=== Using CONFIG_DEBUG_LL and printascii() (ARM only) ===<br />
If the kernel fails before the serial console is enabled, you can use CONFIG_DEBUG_LL<br />
to add extra debug output routines to the kernel. These are printascii, printch and printhex.<br />
These routines print directly to the serial port, bypassing the console code, and are available<br />
earlier in machine initialization.<br />
<br />
Here is an e-mail exchange seen on the linux-embedded mailing list (with answer by George Davis):<br />
<pre><br />
> When we try to boot a 2.6.21 kernel after uncompressing the kernel the boot process dies somehow.<br />
> We've figured out so far that the kernel dies somewhere between the gunzip and start_kernel.<br />
<br />
Try enabling DEBUG_LL to see if it's an machine ID error. If you see:<br />
<br />
Error: unrecognized/unsupported processor variant.<br />
<br />
or:<br />
<br />
Error: unrecognized/unsupported machine ID...<br />
<br />
Then you either don't have proper processor support enabled for your target<br />
or your bootloader is passing in the wrong machine number.<br />
<br />
If you still don't see anything, try hacking printk.c to call<br />
printascii() (enabled for the DEBUG_LL case) to print directly to the<br />
serial port w/o a driver, etc.,. You can find more details on these<br />
low-level debugging hacks via a little googling...<br />
</pre><br />
<br />
== Triggering a kernel event ==<br />
=== Overloading the sync system call ===<br />
Sometimes, it is nice to trigger an event to happen in the kernel from user space.<br />
Instead of creating infrastructure to handle a /proc event, an ioctl() or making a new syscall,<br />
it can be quick and easy to just overload an existing function. One function not used<br />
very often is sync. (I have found that the sync system call is not normally called by user<br />
space programs (or during standard linux booting). <br />
<br />
It is quite easy to put a hook to your own kernel program in the sys_sync() routine<br />
(located in fs/sync.c) and cause it to execute by issuing 'sync' from the shell command line.<br />
This is handy as a temporary mechanism to test things that you have put in the kernel.<br />
[[Category:Development Tools]]<br />
<br />
== Interpreting an Oops message ==<br />
When the kernel encounters an internal fault, it will print an Oops message.<br />
Here are some tips on using the Oops message to find the source of the problem.<br />
* See [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/oops-tracing.txt;hb=HEAD Documentation/oops-tracing.txt]<br />
* See [http://vmlinux.org/jocke/linux/howto-find-oops-location.shtml HOWTO find oops location] by Denis Vlasenko<br />
<br />
== Compilation tricks for the kernel ==<br />
Sometimes, you want to modify how the compiler builds an individual kernel file. The following are tips<br />
for doing tasks related to this.<br />
=== Build an individual file ===<br />
You can build an individual output object file, with:<br />
make fs/buffer.o<br />
<br />
This will build JUST fs/buffer.o (if it needs rebuilding) and not the entire kernel. To force it to<br />
need re-building, use 'touch' on the associated source file: <br />
touch fs/buffer.c<br />
<br />
=== Create the preprocessed file for an individual source file ===<br />
Using the same technique, you can create the preprocessed file for a C source file. This is useful if you're having trouble tracking down macro expansion or where defines/prototypes are coming from exactly.<br />
make fs/buffer.i<br />
<br />
=== Create the assembly file for an individual source file ===<br />
Using the same technique, you can create the assembly file for a C source file. This is useful to <br />
get an idea what actual machine instructions are generated from the C source code.<br />
make fs/buffer.s<br />
<br />
Another way to get the raw assembly, is to dump the object file using 'objdump'<br />
objdump -d fs/buffer.o > fs/buffer.disassem<br />
<br />
This will produce a disassembly of the object file, which should show how the<br />
assembly was translated into machine instructions.<br />
<br />
If the object has been compiled with debug symbols (using '-g'), then you might<br />
get more information using the '-S' option with objdump:<br />
objdump -S -d fs/buffer.o >fs/buffer.disassem<br />
<br />
You can also request that the toolchain show mixed source and assembly, by<br />
passing extra flags:<br />
make EXTRA_CFLAGS="-g -Wa,-a,-ad -fverbose-asm" fs/buffer.o >fs/buffer.mixed<br />
<br />
=== Alter the flags for a compilation ===<br />
Sometimes, you need to alter the compilation flags for an individual file. There are two ways to do this.<br />
One is to add the extra flags on the make command line:<br />
<br />
make EXTRA_CFLAGS="-g -finstrument-functions" fs/buffer.o<br />
<br />
This will work if the flags can be appended to the regular set of C flags used for compiling the object.<br />
<br />
However, if you need to do something more complicated, like removing or modifying flags, then you can<br />
build your own command line by hand. To do this, it is easiest to have 'make' produce the default compilation command (which will be several lines long), then copy, paste and edit it, to run on the command line directly. To see the exact compile commands used to compile a particular object, use the V=1 option with the kernel build system:<br />
<br />
make V=1 fs/buffer.o<br />
<br />
For me, this produced something like this:<br />
<br />
mipsel-linux-gcc -Wp,-MD,fs/.buffer.o.d -nostdinc -isystem /home/usr/local/mipsel-linux-glibc/bin/../lib/gcc/mipsisa32el-linux/3.4.3/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/tbird/work/linux/include -I/home/tbird/work/linux/fs -Ifs -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer -g -I/home/tbird/work/linux/ -I /home/tbird/work/linux/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -finline-limit=100000 -mabi=32 -march=mips32r2 -Wa,-32 -Wa,-march=mips32r2 -Wa,-mips32r2 -Wa,--trap -I/home/tbird/work/linux/include/asm-mips/ati -Iinclude/asm-mips/ati -I/home/tbird/work/linux/include/asm-mips/mach-generic -Iinclude/asm-mips/mach-generic -Wdeclaration-after-statement -DKBUILD_BASENAME=buffer -DKBUILD_MODNAME=buffer -c -o fs/buffer.o /home/tbird/work/linux/fs/buffer.c</div>Vapierhttps://elinux.org/index.php?title=GCC_Tips&diff=10455GCC Tips2009-03-31T08:16:02Z<p>Vapier: add a trick for preprocessing but retaining defines (-E -dD)</p>
<hr />
<div>== What's Here, Why You Should Care ==<br />
<br />
A collection of tips useful to those doing embedded development. Accumulated over several years of doing project work, helping other engineers, untangling projects for customers and feedback from several CELF presentations related to this topic.<br />
<br />
== Tips ==<br />
<br />
=== View Compilation Plan ===<br />
<br />
<pre><br />
gcc -### <the rest of your command line goes here><br />
</pre><br />
<br />
The GCC you run is a driver program for a bunch of other programs. With this parameter, gcc will produce (but not actually execute) the commands it would have used to accomplish the task you asked it to do. This way, you can see the gory details of what's going on behind the scenes. What library is being used? What is -mcpu set to? It's all there. <br />
<br />
You can pipe this output to a file and execute that to compile a program, making it easy to experiment with tweaks to the linker or assembler.<br />
<br />
<pre><br />
Reading specs from /opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/specs<br />
Configured with: ../configure --prefix=/opt/timesys/toolchains/ppc7xx-linux --mandir=/opt/timesys/toolchains/ppc7xx-linux/share/man --infodir=/opt/timesys/toolchains/ppc7xx-linux/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ --with-sysroot=/here/workdir/i386-x-ppc7xx/deleteme --disable-libgcj --build=i686-timesys-linux --host=i686-timesys-linux --target=powerpc-linux --program-prefix=ppc7xx-linux-<br />
Thread model: posix<br />
gcc version 3.4.1 20040714 (TimeSys 3.4.1-7)<br />
/opt/timesys/toolchains/ppc7xx-linux/libexec/gcc/powerpc-linux/3.4.1/cc1 -quiet -v -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -I/opt/timesys/toolchains/ppc7xx-linux/powerpc-linux/include/nptl file.c -quiet -dumpbase file.c -auxbase file -version -o /tmp/ccShiHn4.s<br />
ignoring nonexistent directory "/here/workdir/i386-x-ppc7xx/deleteme/usr/local/include"<br />
ignoring nonexistent directory "/here/workdir/i386-x-ppc7xx/deleteme/usr/include"<br />
#include "..." search starts here:<br />
#include <...> search starts here:<br />
/opt/timesys/toolchains/ppc7xx-linux/powerpc-linux/include/nptl<br />
/opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/include<br />
/opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/../../../../powerpc-linux/include<br />
End of search list.<br />
GNU C version 3.4.1 20040714 (TimeSys 3.4.1-7) (powerpc-linux)<br />
compiled by GNU C version 3.2.2 20030222 (Red Hat Linux 3.2.2-5).<br />
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32138<br />
/opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/../../../../powerpc-linux/bin/as -mppc -many -V -Qy -o /tmp/ccWeV3a3.o /tmp/ccShiHn4.s<br />
GNU assembler version 2.15.90.0.3 (powerpc-linux) using BFD version 2.15.90.0.3 20040415<br />
/opt/timesys/toolchains/ppc7xx-linux/libexec/gcc/powerpc-linux/3.4.1/collect2 --eh-frame-hdr -V -Qy -L/opt/timesys/toolchains/ppc7xx-linux/powerpc-linux/lib/nptl --rpath-link /opt/timesys/toolchains/ppc7xx-linux/powerpc-linux/lib/tls -m elf32ppclinux -dynamic-linker /lib/ld.so.1 -o file /opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/../../../../powerpc-linux/lib/crt1.o /opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/../../../../powerpc-linux/lib/crti.o /opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/crtbegin.o -L/opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1 -L/opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/../../../../powerpc-linux/lib /tmp/ccWeV3a3.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/crtsavres.o /opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/crtend.o /opt/timesys/toolchains/ppc7xx-linux/lib/gcc/powerpc-linux/3.4.1/../../../../powerpc-linux/lib/crtn.o<br />
GNU ld version 2.15.90.0.3 20040415<br />
Supported emulations:<br />
elf32ppclinux<br />
elf32ppc<br />
elf32ppcsim<br />
</pre><br />
<br />
=== Pre-Process, Retain Comments ===<br />
<br />
<pre><br />
gcc -C -E <file-name.c> -o file<br />
</pre><br />
<br />
Some engineers love to do coding in macros. The rest of us would like to break their fingers. This command will run the file through the pre-processor, expanding all macros, but retaining all comments. Stick a comment like "LOOK HERE" and search for that so you reduce the amount of time you spend looking for the offending code.<br />
<br />
=== Pre-Process, Retain Defines/Macros ===<br />
<br />
<pre><br />
gcc -dD -E <file-name.c> -o file<br />
</pre><br />
<br />
Just like the previous example, but perhaps you're trying to trace the macro define mess.<br />
<br />
=== See what Files the Linker is Using ===<br />
<br />
<pre><br />
gcc -Wl,-t <parameters><br />
</pre><br />
<br />
Displays what files the linker opens in what order. When looking in archive files, the archive file is displayed in para theses, followed by the file in the archive. Very handy when working through a legacy project that depends on files linking in a certain order that suddenly breaks because of a small (probably viewed as not noteworthy) change in a makefile somewhere.<br />
<br />
<pre><br />
/usr/bin/ld: mode elf_i386<br />
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crt1.o<br />
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crti.o<br />
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtbegin.o<br />
/tmp/cc37FxnS.o<br />
-lgcc_s (/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/libgcc_s.so)<br />
/lib/libc.so.6<br />
(/usr/lib/libc_nonshared.a)elf-init.oS<br />
-lgcc_s (/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/libgcc_s.so)<br />
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/crtend.o<br />
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../crtn.o<br />
</pre><br />
<br />
=== Print Pre-defined Macros ===<br />
<br />
<pre><br />
gcc -E -dM - < /dev/null | cut -c 9- | sort<br />
</pre><br />
<br />
Very handy when porting code. Lets you know if your target processor has some missing defines or if something is different (line __INT_MAX__) that can have interesting effects on your project. Diff the output from the old to the new compiler so you can easily see the differences, makes it easy to spot problems before getting started. <br />
<br />
Sample output, from a compiler targeting an ARM processor.<br />
<br />
<pre><br />
__APCS_32__ 1<br />
__arm__ 1<br />
__ARM_ARCH_4T__ 1<br />
__ARMEL__ 1<br />
__CHAR_BIT__ 8<br />
__CHAR_UNSIGNED__ 1<br />
__DBL_DENORM_MIN__ 4.9406564584124654e-324<br />
__DBL_DIG__ 15<br />
__DBL_EPSILON__ 2.2204460492503131e-16<br />
__DBL_HAS_DENORM__ 1<br />
__DBL_HAS_INFINITY__ 1<br />
__DBL_HAS_QUIET_NAN__ 1<br />
__DBL_MANT_DIG__ 53<br />
__DBL_MAX_10_EXP__ 308<br />
__DBL_MAX__ 1.7976931348623157e+308<br />
__DBL_MAX_EXP__ 1024<br />
</pre><br />
<br />
=== Mixed Assembler and Source Output ===<br />
<br />
<pre><br />
gcc -g somefile.c -o somefile<br />
objdump -S somefile <br />
</pre><br />
<br />
Prints out each line in the program and the corresponding assembly code. Very handy when you're trying to see that the processor is generating the correct code, with the instructions you're expecting. You can also see the effects of optimization, but would recommend doing this for a small amount of code because when the optimization level is high, there's a much lower relationship between line of code and generated assembler.<br />
<br />
Here's an example of what objdump produces for a few lines of code:<br />
<br />
<pre><br />
gpvSharedMemory = shmat(hSharedMemory, NULL, 0);<br />
10000958: 80 7f 00 10 lwz r3,16(r31)<br />
1000095c: 38 80 00 00 li r4,0<br />
10000960: 38 a0 00 00 li r5,0<br />
10000964: 48 01 09 31 bl 10011294 <shmat@plt><br />
10000968: 7c 60 1b 78 mr r0,r3<br />
1000096c: 3d 20 10 01 lis r9,4097<br />
10000970: 90 09 11 d0 stw r0,4560(r9)<br />
if (errno != 0) {<br />
10000974: 48 01 08 d1 bl 10011244 <__errno_location@plt><br />
10000978: 7c 60 1b 78 mr r0,r3<br />
1000097c: 7c 09 03 78 mr r9,r0<br />
10000980: 80 09 00 00 lwz r0,0(r9)<br />
10000984: 2f 80 00 00 cmpwi cr7,r0,0<br />
10000988: 41 9e 00 50 beq- cr7,100009d8 <main+0x10c><br />
</pre><br />
<br />
=== Specify Language ===<br />
<br />
<pre><br />
gcc -x c a-c-source-file.with-a-non-standard-extension -o test.out<br />
</pre><br />
<br />
Great for legacy projects where where the file extensions don't match with GCC's expectations, while less of a problem since many projects got their start with GCC, this still is an issue with long-running projects that years back, used some other compiler. This stays in effect for the following file on the command line. <br />
<br />
=== List Include File Dependencies ===<br />
<br />
There's a whole family of things around -M. These produce a rule that could be used in a make file, with the included files as dependencies.<br />
<br />
<pre><br />
gcc -M <file name><br />
</pre><br />
<br />
This shows you all includes, even those on the system path. Useful if you're doing porting work or validating if your compiler is working as expected and getting the files from the right place. You'll see something like this for a basic hello world program<br />
<br />
<pre><br />
hello.o: hello.c /usr/include/stdio.h /usr/include/features.h \<br />
/usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \<br />
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/stddef.h \<br />
/usr/include/bits/types.h /usr/include/bits/wordsize.h \<br />
/usr/include/bits/typesizes.h /usr/include/libio.h \<br />
/usr/include/_G_config.h /usr/include/wchar.h /usr/include/bits/wchar.h \<br />
/usr/include/gconv.h \<br />
/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/stdarg.h \<br />
/usr/include/bits/stdio_lim.h /usr/include/bits/sys_errlist.h<br />
</pre><br />
<br />
<pre><br />
gcc -MM <file name> <br />
</pre><br />
<br />
Like -M, but no system files. Great to see if your project is configured and working as expected. <br />
<br />
<pre><br />
gcc -M -MG <file name> <br />
</pre><br />
<br />
The prior -M and -MM commands will stop if header files can be located. The parameter -MG will just produce the dependency list with the missing file. Engineers that have projects that generate header files as part of the build find -MM very handy.<br />
<br />
<pre><br />
gcc -M -MT '<target>' <file name> <br />
</pre><br />
<br />
By default, the target will be the <file name>.o This command will make the default the value of <target>.<br />
<br />
If the command was<br />
<br />
<pre><br />
gcc -M -MT '$(target)' hello.c<br />
</pre><br />
<br />
You would see <br />
<br />
<pre><br />
$(target): hello.c <br />
</pre><br />
<br />
=== Symbol Trace ===<br />
<br />
<pre><br />
gcc -Wl,-y,printf hello.c<br />
</pre><br />
<br />
This is very handy when you want to understand the linker is finding a definition of a symbol. Some projects have name collisions or link order dependencies. This lets you see precisely what the linker is doing.<br />
<br />
Given a hello world program, you would see output like <br />
<br />
<pre><br />
/tmp/ccwZx5UV.o: reference to printf<br />
/lib/libc.so.6: definition of printf<br />
</pre><br />
<br />
The reference is in a temporary file created during the compilation process. If you were linking several object files together explicitly, you would see the name of the object file where printf was referenced.<br />
<br />
=== Saving temporary files ===<br />
<br />
<pre><br />
gcc -save-temps hello.c<br />
</pre><br />
<br />
The compilers temporary files are saved. This is often invaluable dealing with complicated makefiles to peek at the preprocessed output without having to figure out how to do a -E option by hand.</div>Vapier