Samsung Galaxy Grand Duos Oreo Kernel Source
download link-> bottom of the thread.
Linux kernel release 3.x <http://kernel.org/>
These are the release notes for Linux version 3. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong!!
WHAT IS LINUX?
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
It has all the features you would expect in a modern fully-fledged Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.
It is distributed under the GNU General Public License - see the
accompanying COPYING file for more details.
ON WHAT HARDWARE DOES IT RUN?
Although originally developed first for 32-bit x86-based PCs (386 or higher),
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures.
Linux is easily portable to most general-purpose 32- or 64-bit architectures
as long as they have a paged memory management unit (PMMU) and a port of the
GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has
also been ported to a number of architectures without a PMMU, although
functionality is then obviously somewhat limited.
Linux has also been ported to itself. You can now run the kernel as a
userspace application - this is called UserMode Linux (UML).
DOCUMENTATION:
- There is a lot of documentation available both in electronic form on
the Internet and in books, both Linux-specific and pertaining to
general UNIX questions. I'd recommend looking into the documentation
subdirectories on any Linux FTP site for the LDP (Linux Documentation
Project) books. This README is not meant to be documentation on the
system: there are much better sources available.
- There are various README files in the Documentation/ subdirectory:
these typically contain kernel-specific installation notes for some
drivers for example. See Documentation/00-INDEX for a list of what
is contained in each file. Please read the Changes file, as it
contains information about the problems, which may result by upgrading
your kernel.
- The Documentation/DocBook/ subdirectory contains several guides for
kernel developers and users. These guides can be rendered in a
number of formats: PostScript (.ps), PDF, HTML, & man-pages, among others.
After installation, "make psdocs", "make pdfdocs", "make htmldocs",
or "make mandocs" will render the documentation in the requested format.
INSTALLING the kernel source:
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
unpack it:
gzip -cd linux-3.X.tar.gz | tar xvf -
or
bzip2 -dc linux-3.X.tar.bz2 | tar xvf -
Replace "XX" with the version number of the latest kernel.
Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
- You can also upgrade between 3.x releases by patching. Patches are
distributed in the traditional gzip and the newer bzip2 format. To
install by patching, get all the newer patch files, enter the
top level directory of the kernel source (linux-3.x) and execute:
gzip -cd ../patch-3.x.gz | patch -p1
or
bzip2 -dc ../patch-3.x.bz2 | patch -p1
(repeat xx for all versions bigger than the version of your current
source tree, _in_order_) and you should be ok. You may want to remove
the backup files (xxx~ or xxx.orig), and make sure that there are no
failed patches (xxx# or xxx.rej). If there are, either you or me has
made a mistake.
Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
directly to the base 3.x kernel. Please read
Documentation/applying-patches.txt for more information.
Alternatively, the script patch-kernel can be used to automate this
process. It determines the current kernel version and applies any
patches found.
linux/scripts/patch-kernel linux
The first argument in the command above is the location of the
kernel source. Patches are applied from the current directory, but
an alternative directory can be specified as the second argument.
- If you are upgrading between releases using the stable series patches
(for example, patch-3.x.y), note that these "dot-releases" are
not incremental and must be applied to the 3.x base tree. For
example, if your base kernel is 3.0 and you want to apply the
3.0.3 patch, you do not and indeed must not first apply the
3.0.1 and 3.0.2 patches. Similarly, if you are running kernel
version 3.0.2 and want to jump to 3.0.3, you must first
reverse the 3.0.2 patch (that is, patch -R) _before_ applying
the 3.0.3 patch.
You can read more on this in Documentation/applying-patches.txt
- Make sure you have no stale .o files and dependencies lying around:
cd linux
make mrproper
You should now have the sources correctly installed.
SOFTWARE REQUIREMENTS
Compiling and running the 3.x kernels requires up-to-date
versions of various software packages. Consult
Documentation/Changes for the minimum version numbers required
and how to get updates for these packages. Beware that using
excessively old versions of these packages can cause indirect
errors that are very difficult to track down, so don't assume that
you can just update packages when obvious problems arise during
build or operation.
BUILD directory for the kernel:
When compiling the kernel all output files will per default be
stored together with the kernel source code.
Using the option "make O=output/dir" allow you to specify an alternate
place for the output files (including .config).
Example:
kernel source code: /usr/src/linux-3.N
build directory: /home/name/build/kernel
To configure and build the kernel use:
cd /usr/src/linux-3.N
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install
Please note: If the 'O=output/dir' option is used then it must be
used for all invocations of make.
CONFIGURING the kernel:
Do not skip this step even if you are only upgrading one minor
version. New configuration options are added in each release, and
odd problems will turn up if the configuration files are not set up
as expected. If you want to carry your existing configuration to a
new version with minimal work, use "make oldconfig", which will
only ask you for the answers to new questions.
- Alternate configuration commands are:
"make config" Plain text interface.
"make menuconfig" Text based color menus, radiolists & dialogs.
"make nconfig" Enhanced text based color menus.
"make xconfig" X windows (Qt) based configuration tool.
"make gconfig" X windows (Gtk) based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
new config symbols.
"make silentoldconfig"
Like above, but avoids cluttering the screen
with questions already answered.
Additionally updates the dependencies.
"make defconfig" Create a ./.config file by using the default
symbol values from either arch/$ARCH/defconfig
or arch/$ARCH/configs/${PLATFORM}_defconfig,
depending on the architecture.
"make ${PLATFORM}_defconfig"
Create a ./.config file by using the default
symbol values from
arch/$ARCH/configs/${PLATFORM}_defconfig.
Use "make help" to get a list of all available
platforms of your architecture.
"make allyesconfig"
Create a ./.config file by setting symbol
values to 'y' as much as possible.
"make allmodconfig"
Create a ./.config file by setting symbol
values to 'm' as much as possible.
"make allnoconfig" Create a ./.config file by setting symbol
values to 'n' as much as possible.
"make randconfig" Create a ./.config file by setting symbol
values to random values.
You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.txt.
NOTES on "make config":
- having unnecessary drivers will make the kernel bigger, and can
under some circumstances lead to problems: probing for a
nonexistent controller card may confuse your other controllers
- compiling the kernel with "Processor type" set higher than 386
will result in a kernel that does NOT work on a 386. The
kernel will detect this on bootup, and give up.
- A kernel with math-emulation compiled in will still use the
coprocessor if one is present: the math emulation will just
never get used in that case. The kernel will be slightly larger,
but will work on different machines regardless of whether they
have a math coprocessor or not.
- the "kernel hacking" configuration details usually result in a
bigger or slower kernel (or both), and can even make the kernel
less stable by configuring some routines to actively try to
break bad code to find kernel problems (kmalloc()). Thus you
should probably answer 'n' to the questions for
"development", "experimental", or "debugging" features.
COMPILING the kernel:
- Make sure you have at least gcc 3.2 available.
For more information, refer to Documentation/Changes.
Please note that you can still run a.out user programs with this kernel.
- Do a "make" to create a compressed kernel image. It is also
possible to do "make install" if you have lilo installed to suit the
kernel makefiles, but you may want to check your particular lilo setup first.
To do the actual install you have to be root, but none of the normal
build should require that. Don't take the name of root in vain.
- If you configured any of the parts of the kernel as `modules', you
will also have to do "make modules_install".
- Verbose kernel compile/build output:
Normally the kernel build system runs in a fairly quiet mode (but not
totally silent). However, sometimes you or other kernel developers need
to see compile, link, or other commands exactly as they are executed.
For this, use "verbose" build mode. This is done by inserting
"V=1" in the "make" command. E.g.:
make V=1 all
To have the build system also tell the reason for the rebuild of each
target, use "V=2". The default is "V=0".
- Keep a backup kernel handy in case something goes wrong. This is
especially true for the development releases, since each new release
contains new code which has not been debugged. Make sure you keep a
backup of the modules corresponding to that kernel, as well. If you
are installing a new kernel with the same version number as your
working kernel, make a backup of your modules directory before you
do a "make modules_install".
Alternatively, before compiling, use the kernel config option
"LOCALVERSION" to append a unique suffix to the regular kernel version.
LOCALVERSION can be set in the "General Setup" menu.
- In order to boot your new kernel, you'll need to copy the kernel
image (e.g. .../linux/arch/i386/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.
- Booting a kernel directly from a floppy without the assistance of a
bootloader such as LILO, is no longer supported.
If you boot Linux from the hard drive, chances are you use LILO which
uses the kernel image as specified in the file /etc/lilo.conf. The
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image
and copy the new image over the old one. Then, you MUST RERUN LILO
to update the loading map!! If you don't, you won't be able to boot
the new kernel image.
Reinstalling LILO is usually a matter of running /sbin/lilo.
You may wish to edit /etc/lilo.conf to specify an entry for your
old kernel image (say, /vmlinux.old) in case the new one does not
work. See the LILO docs for more information.
After reinstalling LILO, you should be all set. Shutdown the system,
reboot, and enjoy!
If you ever need to change the default root device, video mode,
ramdisk size, etc. in the kernel image, use the 'rdev' program (or
alternatively the LILO boot options when appropriate). No need to
recompile the kernel to change these parameters.
- Reboot with the new kernel and enjoy.
IF SOMETHING GOES WRONG:
- If you have problems that seem to be due to kernel bugs, please check
the file MAINTAINERS to see if there is a particular person associated
with the part of the kernel that you are having trouble with. If there
isn't anyone listed there, then the second best thing is to mail
them to me ([email protected]), and possibly to any other
relevant mailing-list or to the newsgroup.
- In all bug-reports, *please* tell what kernel you are talking about,
how to duplicate the problem, and what your setup is (use your common
sense). If the problem is new, tell me so, and if the problem is
old, please try to tell me when you first noticed it.
- If the bug results in a message like
unable to handle kernel paging request at address C0000010
Oops: 0002
EIP: 0010:XXXXXXXX
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx
ds: xxxx es: xxxx fs: xxxx gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx
or similar kernel debugging information on your screen or in your
system log, please duplicate it *exactly*. The dump may look
incomprehensible to you, but it does contain information that may
help debugging the problem. The text above the dump is also
important: it tells something about why the kernel dumped code (in
the above example it's due to a bad kernel pointer). More information
on making sense of the dump is in Documentation/oops-tracing.txt
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
as is, otherwise you will have to use the "ksymoops" program to make
sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred).
This utility can be downloaded from
ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/ .
Alternately you can do the dump lookup by hand:
- In debugging dumps like the above, it helps enormously if you can
look up what the EIP value means. The hex value as such doesn't help
me or anybody else very much: it will depend on your particular
kernel setup. What you should do is take the hex value from the EIP
line (ignore the "0010:"), and look it up in the kernel namelist to
see which kernel function contains the offending address.
To find out the kernel function name, you'll need to find the system
binary associated with the kernel that exhibited the symptom. This is
the file 'linux/vmlinux'. To extract the namelist and match it against
the EIP from the kernel crash, do:
nm vmlinux | sort | less
This will give you a list of kernel addresses sorted in ascending
order, from which it is simple to find the function that contains the
offending address. Note that the address given by the kernel
debugging messages will not necessarily match exactly with the
function addresses (in fact, that is very unlikely), so you can't
just 'grep' the list: the list will, however, give you the starting
point of each kernel function, so by looking for the function that
has a starting address lower than the one you are searching for but
is followed by a function with a higher address you will find the one
you want. In fact, it may be a good idea to include a bit of
"context" in your problem report, giving a few lines around the
interesting one.
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
possible will help. Please read the REPORTING-BUGS document for details.
- Alternately, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the
kernel with -g; edit arch/i386/Makefile appropriately, then do a "make
clean". You'll also need to enable CONFIG_PROC_FS (via "make config").
After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore".
You can now use all the usual gdb commands. The command to look up the
point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes
with the EIP value.)
gdb'ing a non-running kernel currently fails because gdb (wrongly)
disregards the starting offset for which the kernel is compiled.
Download.
OREO KERNEL SOURCE 3.x
credits:-
@osas514
@GHsR
vasanth36 said:
Samsung Galaxy Grand Duos Oreo Kernel Source
download link-> bottom of the thread.
Linux kernel release 3.x <http://kernel.org/>
These are the release notes for Linux version 3. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong!!
WHAT IS LINUX?
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
It has all the features you would expect in a modern fully-fledged Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.
It is distributed under the GNU General Public License - see the
accompanying COPYING file for more details.
ON WHAT HARDWARE DOES IT RUN?
Although originally developed first for 32-bit x86-based PCs (386 or higher),
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures.
Linux is easily portable to most general-purpose 32- or 64-bit architectures
as long as they have a paged memory management unit (PMMU) and a port of the
GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has
also been ported to a number of architectures without a PMMU, although
functionality is then obviously somewhat limited.
Linux has also been ported to itself. You can now run the kernel as a
userspace application - this is called UserMode Linux (UML).
DOCUMENTATION:
- There is a lot of documentation available both in electronic form on
the Internet and in books, both Linux-specific and pertaining to
general UNIX questions. I'd recommend looking into the documentation
subdirectories on any Linux FTP site for the LDP (Linux Documentation
Project) books. This README is not meant to be documentation on the
system: there are much better sources available.
- There are various README files in the Documentation/ subdirectory:
these typically contain kernel-specific installation notes for some
drivers for example. See Documentation/00-INDEX for a list of what
is contained in each file. Please read the Changes file, as it
contains information about the problems, which may result by upgrading
your kernel.
- The Documentation/DocBook/ subdirectory contains several guides for
kernel developers and users. These guides can be rendered in a
number of formats: PostScript (.ps), PDF, HTML, & man-pages, among others.
After installation, "make psdocs", "make pdfdocs", "make htmldocs",
or "make mandocs" will render the documentation in the requested format.
INSTALLING the kernel source:
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
unpack it:
gzip -cd linux-3.X.tar.gz | tar xvf -
or
bzip2 -dc linux-3.X.tar.bz2 | tar xvf -
Replace "XX" with the version number of the latest kernel.
Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
- You can also upgrade between 3.x releases by patching. Patches are
distributed in the traditional gzip and the newer bzip2 format. To
install by patching, get all the newer patch files, enter the
top level directory of the kernel source (linux-3.x) and execute:
gzip -cd ../patch-3.x.gz | patch -p1
or
bzip2 -dc ../patch-3.x.bz2 | patch -p1
(repeat xx for all versions bigger than the version of your current
source tree, _in_order_) and you should be ok. You may want to remove
the backup files (xxx~ or xxx.orig), and make sure that there are no
failed patches (xxx# or xxx.rej). If there are, either you or me has
made a mistake.
Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
directly to the base 3.x kernel. Please read
Documentation/applying-patches.txt for more information.
Alternatively, the script patch-kernel can be used to automate this
process. It determines the current kernel version and applies any
patches found.
linux/scripts/patch-kernel linux
The first argument in the command above is the location of the
kernel source. Patches are applied from the current directory, but
an alternative directory can be specified as the second argument.
- If you are upgrading between releases using the stable series patches
(for example, patch-3.x.y), note that these "dot-releases" are
not incremental and must be applied to the 3.x base tree. For
example, if your base kernel is 3.0 and you want to apply the
3.0.3 patch, you do not and indeed must not first apply the
3.0.1 and 3.0.2 patches. Similarly, if you are running kernel
version 3.0.2 and want to jump to 3.0.3, you must first
reverse the 3.0.2 patch (that is, patch -R) _before_ applying
the 3.0.3 patch.
You can read more on this in Documentation/applying-patches.txt
- Make sure you have no stale .o files and dependencies lying around:
cd linux
make mrproper
You should now have the sources correctly installed.
SOFTWARE REQUIREMENTS
Compiling and running the 3.x kernels requires up-to-date
versions of various software packages. Consult
Documentation/Changes for the minimum version numbers required
and how to get updates for these packages. Beware that using
excessively old versions of these packages can cause indirect
errors that are very difficult to track down, so don't assume that
you can just update packages when obvious problems arise during
build or operation.
BUILD directory for the kernel:
When compiling the kernel all output files will per default be
stored together with the kernel source code.
Using the option "make O=output/dir" allow you to specify an alternate
place for the output files (including .config).
Example:
kernel source code: /usr/src/linux-3.N
build directory: /home/name/build/kernel
To configure and build the kernel use:
cd /usr/src/linux-3.N
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install
Please note: If the 'O=output/dir' option is used then it must be
used for all invocations of make.
CONFIGURING the kernel:
Do not skip this step even if you are only upgrading one minor
version. New configuration options are added in each release, and
odd problems will turn up if the configuration files are not set up
as expected. If you want to carry your existing configuration to a
new version with minimal work, use "make oldconfig", which will
only ask you for the answers to new questions.
- Alternate configuration commands are:
"make config" Plain text interface.
"make menuconfig" Text based color menus, radiolists & dialogs.
"make nconfig" Enhanced text based color menus.
"make xconfig" X windows (Qt) based configuration tool.
"make gconfig" X windows (Gtk) based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
new config symbols.
"make silentoldconfig"
Like above, but avoids cluttering the screen
with questions already answered.
Additionally updates the dependencies.
"make defconfig" Create a ./.config file by using the default
symbol values from either arch/$ARCH/defconfig
or arch/$ARCH/configs/${PLATFORM}_defconfig,
depending on the architecture.
"make ${PLATFORM}_defconfig"
Create a ./.config file by using the default
symbol values from
arch/$ARCH/configs/${PLATFORM}_defconfig.
Use "make help" to get a list of all available
platforms of your architecture.
"make allyesconfig"
Create a ./.config file by setting symbol
values to 'y' as much as possible.
"make allmodconfig"
Create a ./.config file by setting symbol
values to 'm' as much as possible.
"make allnoconfig" Create a ./.config file by setting symbol
values to 'n' as much as possible.
"make randconfig" Create a ./.config file by setting symbol
values to random values.
You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.txt.
NOTES on "make config":
- having unnecessary drivers will make the kernel bigger, and can
under some circumstances lead to problems: probing for a
nonexistent controller card may confuse your other controllers
- compiling the kernel with "Processor type" set higher than 386
will result in a kernel that does NOT work on a 386. The
kernel will detect this on bootup, and give up.
- A kernel with math-emulation compiled in will still use the
coprocessor if one is present: the math emulation will just
never get used in that case. The kernel will be slightly larger,
but will work on different machines regardless of whether they
have a math coprocessor or not.
- the "kernel hacking" configuration details usually result in a
bigger or slower kernel (or both), and can even make the kernel
less stable by configuring some routines to actively try to
break bad code to find kernel problems (kmalloc()). Thus you
should probably answer 'n' to the questions for
"development", "experimental", or "debugging" features.
COMPILING the kernel:
- Make sure you have at least gcc 3.2 available.
For more information, refer to Documentation/Changes.
Please note that you can still run a.out user programs with this kernel.
- Do a "make" to create a compressed kernel image. It is also
possible to do "make install" if you have lilo installed to suit the
kernel makefiles, but you may want to check your particular lilo setup first.
To do the actual install you have to be root, but none of the normal
build should require that. Don't take the name of root in vain.
- If you configured any of the parts of the kernel as `modules', you
will also have to do "make modules_install".
- Verbose kernel compile/build output:
Normally the kernel build system runs in a fairly quiet mode (but not
totally silent). However, sometimes you or other kernel developers need
to see compile, link, or other commands exactly as they are executed.
For this, use "verbose" build mode. This is done by inserting
"V=1" in the "make" command. E.g.:
make V=1 all
To have the build system also tell the reason for the rebuild of each
target, use "V=2". The default is "V=0".
- Keep a backup kernel handy in case something goes wrong. This is
especially true for the development releases, since each new release
contains new code which has not been debugged. Make sure you keep a
backup of the modules corresponding to that kernel, as well. If you
are installing a new kernel with the same version number as your
working kernel, make a backup of your modules directory before you
do a "make modules_install".
Alternatively, before compiling, use the kernel config option
"LOCALVERSION" to append a unique suffix to the regular kernel version.
LOCALVERSION can be set in the "General Setup" menu.
- In order to boot your new kernel, you'll need to copy the kernel
image (e.g. .../linux/arch/i386/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.
- Booting a kernel directly from a floppy without the assistance of a
bootloader such as LILO, is no longer supported.
If you boot Linux from the hard drive, chances are you use LILO which
uses the kernel image as specified in the file /etc/lilo.conf. The
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image
and copy the new image over the old one. Then, you MUST RERUN LILO
to update the loading map!! If you don't, you won't be able to boot
the new kernel image.
Reinstalling LILO is usually a matter of running /sbin/lilo.
You may wish to edit /etc/lilo.conf to specify an entry for your
old kernel image (say, /vmlinux.old) in case the new one does not
work. See the LILO docs for more information.
After reinstalling LILO, you should be all set. Shutdown the system,
reboot, and enjoy!
If you ever need to change the default root device, video mode,
ramdisk size, etc. in the kernel image, use the 'rdev' program (or
alternatively the LILO boot options when appropriate). No need to
recompile the kernel to change these parameters.
- Reboot with the new kernel and enjoy.
IF SOMETHING GOES WRONG:
- If you have problems that seem to be due to kernel bugs, please check
the file MAINTAINERS to see if there is a particular person associated
with the part of the kernel that you are having trouble with. If there
isn't anyone listed there, then the second best thing is to mail
them to me ([email protected]), and possibly to any other
relevant mailing-list or to the newsgroup.
- In all bug-reports, *please* tell what kernel you are talking about,
how to duplicate the problem, and what your setup is (use your common
sense). If the problem is new, tell me so, and if the problem is
old, please try to tell me when you first noticed it.
- If the bug results in a message like
unable to handle kernel paging request at address C0000010
Oops: 0002
EIP: 0010:XXXXXXXX
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx
ds: xxxx es: xxxx fs: xxxx gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx
or similar kernel debugging information on your screen or in your
system log, please duplicate it *exactly*. The dump may look
incomprehensible to you, but it does contain information that may
help debugging the problem. The text above the dump is also
important: it tells something about why the kernel dumped code (in
the above example it's due to a bad kernel pointer). More information
on making sense of the dump is in Documentation/oops-tracing.txt
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
as is, otherwise you will have to use the "ksymoops" program to make
sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred).
This utility can be downloaded from
ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/ .
Alternately you can do the dump lookup by hand:
- In debugging dumps like the above, it helps enormously if you can
look up what the EIP value means. The hex value as such doesn't help
me or anybody else very much: it will depend on your particular
kernel setup. What you should do is take the hex value from the EIP
line (ignore the "0010:"), and look it up in the kernel namelist to
see which kernel function contains the offending address.
To find out the kernel function name, you'll need to find the system
binary associated with the kernel that exhibited the symptom. This is
the file 'linux/vmlinux'. To extract the namelist and match it against
the EIP from the kernel crash, do:
nm vmlinux | sort | less
This will give you a list of kernel addresses sorted in ascending
order, from which it is simple to find the function that contains the
offending address. Note that the address given by the kernel
debugging messages will not necessarily match exactly with the
function addresses (in fact, that is very unlikely), so you can't
just 'grep' the list: the list will, however, give you the starting
point of each kernel function, so by looking for the function that
has a starting address lower than the one you are searching for but
is followed by a function with a higher address you will find the one
you want. In fact, it may be a good idea to include a bit of
"context" in your problem report, giving a few lines around the
interesting one.
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
possible will help. Please read the REPORTING-BUGS document for details.
- Alternately, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the
kernel with -g; edit arch/i386/Makefile appropriately, then do a "make
clean". You'll also need to enable CONFIG_PROC_FS (via "make config").
After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore".
You can now use all the usual gdb commands. The command to look up the
point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes
with the EIP value.)
gdb'ing a non-running kernel currently fails because gdb (wrongly)
disregards the starting offset for which the kernel is compiled.
Download.
OREO KERNEL SOURCE 3.x
credits:-
@osas514
@GHsR
Click to expand...
Click to collapse
How is it going to help us?
Repo deleted
Related
New: SANE (USB Scanner backend and drivers) - OTG equipped device needed to work for this - YES, Scanner Access Now possible and Easy with your phone
This can (in combination with tesseract-ocr) be very useful to recognize text from scanned images.
For pictures see also http://forum.xda-developers.com/showpost.php?p=23046120&postcount=187
Update 01/30/2012: Now with a small android app (ScriptStarter) to start services and other shell scripts easily from the GUI. See bottom of the post.
WHAT'S POSSIBLE WITH THIS SCRIPT:
With this bash script your are able to build relatively easy from source a lot of native software (over 90 at the moment) from the GNU/Linux community for your Android phone and you will have
the good experience with free software.
All these tools and programs are not "apps for the GUI" for Android but native running command line tools "under the surface" of your Android GUI like the kernel and other services.
Don't ask me if it makes any sense to install program xy (like MySQL) on a phone. This is your decision. It's possible, so try it and see what you can do with it.
Note: I tested most of the compiled software on a Samsung Galaxy S2 (my phone). I cannot test it on a variety of phones because I have no mobile phone shop...
Currently buildable with this scripts (abstract, see the full list in package_selection.conf):
PHP 5.3.10 (with almost all extensions and XCache)
MySQL 5.5.19 (if you want a full database server on your phone...)
lighttpd 1.4.30
OpenSSH 5.9p1
OpenSSL 1.0.0f
Samba 3.6.3
cURL 7.23.1
bash 4.2
BusyBox 1.19.3
ImageMagick 6.7.4-10
OpenVPN 2.2.2
Python 2.7.2
Node.js 0.6.7
git 1.7.9
Wget 1.13.4
Rsync 3.0.9
TCPDUMP 4.2.0
Midnight Commander 4.8.1
Pure-FTPd 1.0.35
screen 4.0.3
iptables 1.4.10 (without bionic bug "getnetbyaddr()" and with iptables-save/restore!)
BIND 9.8.1-P1
Lua 5.2.0
Ruby 1.9.3-p0
usbutils 004
MTDUtils latest git
GCC 4.6.2 (c, c++)
GNU Coreutils 8.14, Binutils 2.22, Findutils 4.4.2, Inetutils 1.8
QEMU 0.15.1
SANE 1.0.22
tesseract-ocr 3.01
...
a lot of libraries, development tools and other useful programs
...
FEATURES:
automatic download and untar the cross-compilers (if not already done) for cross compiling
automatic download and untar the source packages (if not already done), that you have selected
solve dependences and reserves additional needed packages
apply patches to the sources if necessary
build them, "install" them in a folder for later "ready to transfer" to your phone and stripes the binaries and libraries to reduce the filesize if selected
autogenerate a tar file and adb push the file to device if selected
allows you to use well-known software like PHP, MySQL, OpenSSL, OpenSSH, OpenVPN, bash and lighttpd on your phone (see the full list in file package_selection.conf, see attachement)
scripting and development on your phone
no limits with BusyBox (without want to be derogative, BusyBox is a wonderful tool), full featured tools like Coreutils, Binutils etc.
build scripts are expandable with other or newer packages you eventual want to have
QUESTIONS AND ANSWERS:
Q: Do I need native GNU/Linux programs and what is that?
A: If you do not know what native Linux applications are, then stop here - you don't need them.
Q: What can I do with these tools?
A: Many things. As a developer you can use the libraries to include them in Android GUI apps, as user you can start for example a webserver on your phone and write some HTML or PHP pages
just for fun or replace BusyBox with full featured tools (or only some commands).
Some tools are also very useful to find network errors, check the network traffic and many more.
Q: What do I need?
A: A Linux installation (VM or real), some Linux knowledge and a little bit time to read all instructions carefully. A rooted Android device with enouth free memory (ext2/3/4 formatted)
See README for details.
Q: Costs?
A: Nothing. The scripts are Open Source (GPL v3), the packages are GPL licensed or under a similar license. The cross-compilers are Open Source or free to use for non-profit purposes.
But I would be pleased if I get a donation and/or a press on the "Thanks button", if the scripts are useful for you. It was a long and hard work...
Note: The attachement scriptset-x.yy.zip is double packed (inside .bz2), because I want preserve the right settings of the scripts.
STEPS:
Selected the desired packages in the config file
Adjust the compiler settings for your phone
Run the build script to download and compile the software
Copy the generated TAR files to your phone or let "adb" this do for you and unpack them in the prepared sysroot folder
For more information please read the instructions in "README"
Please let me also know if you have any problems or if you have questions or further suggestions.
Thanks go to the Open Source community and a lot of people/webpages with hints about cross-compiling software.
Thanks
smitna
CHANGELOG:
01/14/2012 First public release v0.9
01/14/2012 Update: Removed unneeded big patch for ncurses
01/15/2012 Release of v1.0
Update: Fixed build of gcc. Note: the header files are not copied automatically with the script.
If you want to compile on your phone, set TAR_HEADERS=1 in configuraton.conf
Typos: some translations corrected in build.sh
01/16/2012 Release of v1.1
Update: Removed building of fsck from util-linux-ng, it's in e2fsprogs
Update: ISC Cron / vixie cron: set correct paths in pathnames.h before compiling
Enhancement: More detailed explanation of device specific compiler settings with list of possible values
Update: Removed dependence e2fsprogs libs from e2fsprogs
01/17/2012 Release of v1.2
Update: Build of zip, zipcloak, zipnote, zipsplit, unzip, unzipsfx and funzip now possible without errors
01/17/2012 Release of v1.3
Update: Added Node.js
Typos: some translations and language errors corrected in build.sh and README (sorry, I'm not a native English speaker...)
01/18/2012 Release of v1.4
Fixed TMP_PATH in PHP extension XCache (mmap.c) to prevent startup warning
Fixed BusyBox problems with static build against glibc ("__getpagesize" segfault with ping, traceroute and other networking parts)
and added some BusyBox patches.
BusyBox is now dynamic linked, so don't replace the system BusyBox with this build, because of missing mount/paths to libraries at phone startup
01/20/2012 Release of v1.5
Update: Cleanup in scripts and separation of configuration and code. Now it's only necessary to edit configuration.conf and package_selection.conf
Update: Added gzip
Update: Added experimental adb push to device if the device is connected and permissions are ok
Update: Check for installed programs. Script now exists on check failure to minimize errors while compiling.
01/21/2012 Release of v1.6
Bugfix: MySQL build could fail if gen_lex_hash could not generate the file sql/lex_hash.h in pass 2
Update: adb push should now work, check for connected device (and possible multiple devices) and check for right permissions to use the device
Enhancement: Even more explanation of device specific compiler flags and some hints to find the right settings.
01/21/2012 Release of v1.7
Enhancement: To eliminate sure a failing MySQL build, with every new run the source folder will be removed before completely
Enhancement: file version is now strictly checked (the host version must be the same as the cross version)
Some minor changes and filechecks (e.g. autoconf)
01/23/2012 Release of v1.8
Bugfix: Python has SQLite dependencies and SQLite must be ready before Python configure/make
Bugfix: In certain circumstances the optimizer settings get lost
Bugfix: Removed --enable-multibyte from bash, no chance to use it with NDK
01/24/2012 Release of v1.9
Update: Added ngIRCd (Please read the comment for this server, because of running as root)
Update: Sorted the links and package names in the config a little bit...
01/26/2012 Release of v2.0
Bugfix: OpenSSH wants to touch /var/empty while compiling, should be fixed --with-privsep-path now set (thanks to member dateno1 for his reports of such warnings/errors)
Bugfix: Removed a wrong CFLAG -I path from NDK config (only useful for me, really useless for others...)
Enhancement: Example for a user db for Pure-FTPd virtual user database in README (please use virtual users, it's the best and easiest solution)
Update: OpenSSH build need ssh-keygen for the generation of the default keys, added this info to README and the package selection
Bugfix: Not really a bugfix, but some installers don't set the right permissions of libraries in the sysroot folder, so set them global in the final task
Bugfix: Removed --with-lastlog=$TARGET_SYSROOT/var/log/lastlog from OpenSSH and added --with-lastlog=no, I don't know why this is not working and throws a warning, but we can live without it...
Enhancement: Added option to choose the sysroot variant from the CodeSourcery libs: v5TE (default), v4T (old), thumb2 (v7, fastest if supported by the phone)
Enhancement: Added option to tar the headers for development on the device with CodeSourcery (hint: always set rpath in LDFLAGS to make use of the CodeSourcery libs)
01/26/2012 Release of v2.1
Update: Added getcap/setcap and libraries from wishlist, needs libtoolize. Note: This is in a testing stage, kernel and filesystem support needed!
01/30/2012 Added a ScriptStarter app
09/02/2012 Release of v2.2
Update: Local compilation of static "tic" from ncurses for buildhost, if ncurses installation is missing
Enhancement: "downloading only" mode without compiling the packages (and force download)
Enhancement: some parameters for starting the script with additional functions (show with ./build.sh help)
Enhancement: more logging and outputs
Enhancement: language specs, all outputs can be changed to other languages in build.sh
Update: Added dosfstools
Update: Added Ruby
Update: Added example configs and starter scripts for Samba and OpenSSH
Update: Use of http-URLs if possible and update of some broken external links since last release
Bugfix: util-linux-ng needs gettext, added dependence
Bugfix: Added parameter to Samba to solve user/group settings and socket_wrapper support to set path vars at runtime
Update: Changed PHP version to 5.3.10, Samba to 3.6.3 and git to 1.7.9
02/11/2012 internal Release v2.3
Bugfix: openVPN patch for /dev/tun and links to ip/netstat/ifconfig/route, see hints for symlinks
02/16/2012 internal Release v2.4
02/25/2012 Release of v2.5
Update: Added LAME
Update: Added experimental CUPS
Update: Changed PNG version to 1.5.9
Update: Added Net-SNMP
Update: Added Netpbm
Update: Added PNG 1.2.47 for Netpbm and phpSANE
Update: Added LibTIFF
Update: Added SANE (USB Scanner backend and drivers) - OTG equipped device needed to work for this - YES, Scanner Access Now possible and Easy with your phone
Update: Split patches for bash (4.1 and 4.2) for better and easier (automatic) inclusion of original patches
02/28/2012 Release of v2.6
Update: Added Cuneiform OCR
Update: Added tesseract-ocr (see hints for more details howto use it)
ScriptStarter
02/03/2012 Added a small ScriptStarter for the GUI. With this app, written with JQuery, PhoneGap and Java (wrapper to execute the shell scripts) it's possible to start for example the lighttpd web server, Pure-FTPd or MySQL from within the Android GUI without a terminal and read the output. If a script needs root access, there is a checkbox to allow this. For this to work, copy the script sush in the script folder. All scripts ending with .sh can be started (please choose after the first start your script folder on the device to add the scripts to the selection, normally your [SYSROOT]/sbin folder).
Three buttons (start, stop and status) are predefined for start-stop-status scripts, there is also a parameter input field for more start values.
Free GPL v3 source code also included (Eclipse project). Please don't expect too much eye-candy. The GUI could be much better, but my CSS skills are very limited...
I added a few example scripts in the zip file, for example a battery stats reader. Before starting these scripts, have a look in the source code to be sure that they are compatible with your device.
Update 0.97 02/03/2012: Now the stderr is also printed in the output window
Update 0.99 02/10/2012: Replaced scrolling api with a much better solution (jScrollPane) for the output window. Not the real Android scroll feeling, but it's usable.
Thanks! I would hit the Thanks button, but I am on my mobile atm.
Sent from MIUI powered phone
Someone tried it? Problems?
Please, I need your feedback...
Sounds interesting, I'll try once I get back home and share feedback here
now i try to all packages for test
i will test on cortex a8 (motolora xt720)
TARGET_MARCH="armv7-a" (not work on armv7 )
TARGET_MTUNE="cortex-a8"
TARGET_MFPU="neon"
TARGET_MFLOAT="softfp"
it make dynamic binarys but i don't want dymanic type (because it difficult to divide one thing and maybe not work on android's libs)
how can i make static type?
ps : oh...it has so many comile error (even can't read or count all)
dateno1 said:
i will test on cortex a8 (motolora xt720)
TARGET_MARCH="armv7-a" (not work on armv7 )
TARGET_MTUNE="cortex-a8"
TARGET_MFPU="neon"
TARGET_MFLOAT="softfp"
it make dynamic binarys but i don't want dymanic type (because it difficult to divide one thing and maybe not work on android's libs)
Click to expand...
Click to collapse
I hope I understand your question. Why not dynamic?
Yes, you have to set the parameters for your mobile phone. For TARGET_MARCH try "armv7", for TARGET_MFLOAT "softfp" and for TARGET_MFPU "vfp" but check this last setting carefully for this phone.
It's very hard to build a full static binary (and sometimes nearly impossible) and it's also hard to build against bionic (with NDK). I had no good experience with it . A lot of compiler runs wasn't sucessful. Edit: I also had for example massive problems with openssl. I couldn't find a way to build it with NDK or static and then build other programs like cURL with openssl support.
Static binaries are also too big and not necessary. For this we have a sysroot environment to be independent from bionic and without the restrictions. The compiled libs and binaries are linked to the CodeSourcery glibc and have set the custom "rpath" for the dynamic loader. That's no problem I think.
that's simple
if someone want to make some binary for all version of android (even same cpu) it will not work well (defend on basic lib(ex : libc) is ok but complex things will not work)
i know make static type binary is very difficult but it valable
dateno1 said:
that's simple
if someone want to make some binary for all version of android (even same cpu) it will not work well (defend on basic lib(ex : libc) is ok but complex things will not work)
i know make static type binary is very difficult but it valable
Click to expand...
Click to collapse
You are right, if you want to build a "portable" binary, you have to set very safe settings, like TARGET_MARCH="armv5", the full list is in the "README". But it's not my main target to offer a solution that is easy portable to other phones, instead you can build the software with optimizations for your phone to "get the best" for it
smitna said:
You are right, if you want to build a "portable" binary, you have to set very safe settings, like TARGET_MARCH="armv5", the full list is in the "README". But it's not my main target to offer a solution that is easy portable to other phones, instead you can build the software with optimizations for your phone to "get the best" for it
Click to expand...
Click to collapse
just i want to add some more function on the phone
thanks for patch files
I want to try this, to install some apps(most interested fro mc), but I don' t wanna change my sd card.
Can I use phone' s /data partition as mysysroot directory? I have 1.5GB space available on data partition, it is 2GB all.
And If yes, I must create the dir: /data/mysyroot? And where to create this dir on pc? On root directory of my linux system?
dancer_69 said:
I want to try this, to install some apps(most interested fro mc), but I don' t wanna change my sd card.
Can I use phone' s /data partition as mysysroot directory? I have 1.5GB space available on data partition, it is 2GB all.
And If yes, I must create the dir: /data/mysyroot? And where to create this dir on pc? On root directory of my linux system?
Click to expand...
Click to collapse
You can use the /data partition. Just create a new folder, for example /data/sysroot. On your PC you have to create the same temporary with full user rights. This is not your working dir for building. Create a new dir in /home/user and unpack the files there. In settings insert the /data/sysroot as TARGET_SYSROOT and change the other settings for your phone and choose mc=yes. Then start the ./build.sh
Thanks for your quick answer.
Just to make clear because my english understanding is not in a high level
I must create the /data/sysroot dir under "/"(root directory) on linux pc with superuser rights?
dancer_69 said:
Thanks for your quick answer.
Just to make clear because my english understanding is not in a high level
I must create the /data/sysroot dir under "/"(root directory) on linux pc with superuser rights?
Click to expand...
Click to collapse
Yes, that is right. But this is the only step you need to do as root or better with root rights. After this work as usual as user.
oh it can't make mysql
package selection : mysql only
target directory (prefix) : /sddata/mysql (on sdext on my system)
armv7-a
cortex-a8
neon
softfp
then run ./build.sh 2> error.txt
it is my error messages
http://pastebin.com/g7Yi4bGz
sorry you can see this link only today (my mistake)
this setting can make some binary and lib run on my phone but fail to make gcc or mysql (when i try gcc it just fail to making gcc only (other things were made) )
dateno1 said:
package selection : mysql only
target directory (prefix) : /sddata/mysql (on sdext on my system)
armv7-a
cortex-a8
neon
softfp
then run ./build.sh 2> error.txt
it is my error messages
http://pastebin.com/g7Yi4bGz
sorry you can see this link only today (my mistake)
this setting can make some binary and lib run on my phone but fail to make gcc or mysql (when i try gcc it just fail to making gcc only (other things were made) )
Click to expand...
Click to collapse
Please notice first, that you should not run this script as root!!
Then there is something wrong with the build of the first needed packages:
ZLIB=yes
OPENSSL=yes
CURL=yes
GETTEXT=yes
LIBXML2=yes
READLINE=yes
NCURSES=yes
- The script cannot find the readline sources. Do you have a subfolder readline-6.2 in folder sources in your builddir? Same for the other source folders. The script first downloads the packages to folder packages, extract the tars in folder sources, repeated for all selections.
(look at line 67 in your log: ./build.sh: 1402: cd: Python-2.7.2: No such file or directory)
- You have no "xz", install it first and make sure, that the other necessary packages are installed. MySQL and gcc are "two pass" compilations and this builds generating temporary binaries, runable on your linux pc. So you need all for a successful compilation of such binaries like gcc, make, python etc. on your linux machine. If you are using Ubuntu, then install the "meta-package" build-essential, look in the README.
Do you have the other unpacking tools like gunzip etc. Please install also "bison"
You should do following steps:
1. First select only the necessary packages (see above), all others to no.
2. If zlib, python, readline an the others are cross-compiled (without errors) and the libraries are in ./sysroot/lib, then deselect them (=no) and select mysql=yes and start a second run with ./build.sh
smitna said:
Please notice first, that you should not run this script as root!!
Then there is something wrong with the build of the first needed packages:
ZLIB=yes
OPENSSL=yes
CURL=yes
GETTEXT=yes
LIBXML2=yes
READLINE=yes
NCURSES=yes
- The script cannot find the readline sources. Do you have a subfolder readline-6.2 in folder sources in your builddir? Same for the other source folders. The script first downloads the packages to folder packages, extract the tars in folder sources, repeated for all selections.
(look at line 67 in your log: ./build.sh: 1402: cd: Python-2.7.2: No such file or directory)
- You have no "xz", install it first and make sure, that the other necessary packages are installed. MySQL and gcc are "two pass" compilations and this builds generating temporary binaries, runable on your linux pc. So you need all for a successful compilation of such binaries like gcc, make, python etc. on your linux machine. If you are using Ubuntu, then install the "meta-package" build-essential, look in the README.
Do you have the other unpacking tools like gunzip etc. Please install also "bison"
You should do following steps:
1. First select only the necessary packages (see above), all others to no.
2. If zlib, python, readline an the others are cross-compiled (without errors) and the libraries are in ./sysroot/lib, then deselect them (=no) and select mysql=yes and start a second run with ./build.sh
Click to expand...
Click to collapse
i'm not edit necessary part
ZLIB=yes
OPENSSL=yes
CURL=yes
GETTEXT=yes
LIBXML2=yes
READLINE=yes
NCURSES=yes
i just edit mysql=no => mysql=yes
ok try to install packages and run as not root
dateno1 said:
i'm not edit necessary part
ZLIB=yes
OPENSSL=yes
CURL=yes
GETTEXT=yes
LIBXML2=yes
READLINE=yes
NCURSES=yes
i just edit mysql=no => mysql=yes
ok try to install packages and run as not root
Click to expand...
Click to collapse
Good luck!
If you can wait a little bit:
In a short time I release a new version with better error and program checks and some small bug fixes. With this version it's not longer necessary to edit the build.sh, it's now all in only two separated configuration files (configuration and package selection).
hmm...fail to compile mysql again
with this error
note: the mangling of 'va_list' has changed in GCC 4.4
full error log on http://pastebin.com/jd1Pw9Xw
dateno1 said:
with this error
note: the mangling of 'va_list' has changed in GCC 4.4
full error log on http://pastebin.com/jd1Pw9Xw
Click to expand...
Click to collapse
Hello dateno1,
first: you have *NOT* changed to a user account as promised
The va_list is only a note, not an error, no problem (but ask the MySQL devs why they haven't adapted the code to gcc 4.6.1).
Your Python cross binaries and libraries are not ok (from you broken first build?). Please start from a "fresh state" (delete the folder sources/Python-2.7.2 and sysroot) or start from a total clean state.
Please use the latest 1.5 version of the script because of the xargs warnings at the end
Delete the complete sysroot folder, there are some folders not in place (data and docs). There is a script remove_all_files.sh
Start this script in your buildroot with ./remove_all_files.sh to remove all files and symlinks in subfolder sysroot.
Edit: delete the sysroot folder complete, there are some other missing folders from your first build!
Start again with ./build.sh and activated packages (the "ALWAYS NEEDED" one and MySQL)
smitna said:
Hello dateno1,
first: you have *NOT* changed to a user account as promised
The va_list is only a note, not an error, no problem (but ask the MySQL devs why they haven't adapted the code to gcc 4.6.1).
Your Python cross binaries and libraries are not ok (from you broken first build?). Please start from a "fresh state" (delete the folder sources/Python-2.7.2 and sysroot) or start from a total clean state.
Please use the latest 1.5 version of the script because of the xargs warnings at the end
Delete the complete sysroot folder, there are some folders not in place (data and docs). There is a script remove_all_files.sh
Start this script in your buildroot with ./remove_all_files.sh to remove all files and symlinks in subfolder sysroot.
Edit: delete the sysroot folder complete, there are some other missing folders from your first build!
Start again with ./build.sh and activated packages (the "ALWAYS NEEDED" one and MySQL)
Click to expand...
Click to collapse
make new account (compile.compile) and use su -c "./build.sh" compile
i think it work (compiled file's owner is changed to compile.compile)
now i delete almost files and folders (exclude android-ndk, readline-6.2, toolchains) and retrying...oh failed (attach new log (full) )
'를 위해 할 일이 없습니다' mean 'no job for~'
'오류' mean 'error'
The following contains binaries, and instructions for use of an experimental newer toolchain than those included in the android pre-built package.
This is provided to allow existing linux kernel developers experiment with the updated version of GCC (besides the complicated building instructions the code just has a small patch for a known issue with android and 4.6.* otherwise is directly from GNU (see build information below)
The packages I'm also providing to help developers current on windows (With cygwin but no other virtual environment) to start exploring android Linux kernel development for their devices. (In addition to a OSX toolchain for more advanced mac users)
due to the slight differences between kernels on different devices this How To is intended to be used for advanced users who can adjust for the differences required for the devices specific kernel.
I may add additional guides to this thread if I find a need for them.
[size=+1]Binary Toolchains[/size]
I have two versions of a GCC-4.6.3 toolchain
1) For x86 linux: toolchain-4.6.3.tar.bz2 (Sha1: c8c57aba6ad92e9acddf29ba8620ba880be09a81)
2) For Cygwin (windows): toolchain-4.6.3.cygwin.tar.bz2 (Sha1: 6947e1c1ba95195019f542eb8ba0708667b63eca)
3) For OSX (mac/darwin): toolchain-4.6.3.darwin.tar.bz2 (Sha1: 9a977f0672863fdd9501383a6ad1e30723281f68)
[size=-1]> The linux version was built via this script: http://pastebin.com/b2dZ8YtG (or in the included toolchain_notes.txt)
> The cygwin/darwin version uses the same source however has a slightly modified script (see the included toolchain_notes.txt for the updated script)[/size]
[size=+1]System Requirements[/size]
Note I have a 64bit debian linux box, and a 64bit version of WIndows7 Pro running cygwin, while I believe these binaries ought to be compatible with all x86 linux and cygwin installs these have not been tested by a wide number of people yet.
> Linux users: If you have a working android build environment likely no additional requirements are needed. In addition you must build any kernel/android utilities from a case sensitive filesystem or disk image.
> OSx users: the cygwin packages will give you an idea of what is required, please also see the README in the tar.bz2 about manually installing elf.h
> Cygwin users: as its unlikely you have compiled a kernel with cygwin up to this point you may wish to ensure the following packages are installed (as well as any cygwin recommends to be used with them):
vim
vim-common
make
cmake
lzop
gcc
gcc-core
gcc-g++
wget
git
git-compleation
libncurses-devel
python
Cygwin users must also set their NTFS file partition to allow case sensitive files:
To do this open regedit and change:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive
to 0
after this reboot and the NTFS kernel will allow cygwin to use case sensitive files (ie 'AbC' and 'aBc' as two different files)
[size=+1]Advanced Kernel Building Guide[/size]
Since may devices are slightly different this can only be a high level kernel building guide
Please ask for any specific directions from the current kernel maintainer.
To most people who have built kernels before this will look familiar, the most important part is preparing your local environment to use the new toolchain,
1) If you have not already download the tar.bz2 above, (pick the one for the computer you are preparing to build kernels on)
2) extract the file (for the sake of this guide I will assume it is extracted into a ~/android directory)
ie on cygwin you might:
mkdir -p ~/android
cd ~/android
tar -xjvf toolchain-4.6.3.cygwin.tar.bz2
Note: steps one and two are just properly installing the toolchain, you will not need
to repeat them to build a different kernel.
2.b) OSX Only: check elf.h
open ~/android/toolchain-4.6.3/README in a text editor and check if elf.h is installed, otherwise manually install it as per the readme
3) fetch your kernel source into the ~/android directory and change into the
source codes root directory
(this can be via a git repo or tarball)
example if you wanted my ACER a100/a500 source you might run:
git clone git://github.com/ezterry/AcerTabKernel.git
cd AcerTabKernel
change this to match the source you are fetching
4) In the root directory of the kernel source (~/android/AcerTabKernel in the about a100/a500 example) update the environment for the cross compiler
add the toolchain to your path:
export PATH=$HOME/android/toolchain-4.6.3/bin:$PATH
set the cross compile:
export ARCH=arm
export CROSS_COMPILE=arm-linux-androideabi-
export KERNEL_DIR=`pwd`
(this will need to be done once for each terminal you use to run any of the following make commands)
5) Grab your configuration
From the device:
adb pull /proc/config.gz
gzip -dc config.gz > .config
or from a prepared configuration if it's included in your code base by running
make _defconfig
example for the a100/a500 code base is 'make vangogh_defconfig' for the a100 and 'make picasso_defconfig' for the a500
6) Customize configuration
just run menuconfig and use the UI to update settings
make menuconfig
7) building the kernel (zImage)
This is normal at this point with 'make -j'
so for a quad core CPU you can run
make -j5
(note: the wrong number in the -j argument will not harm the build but may slow down the building process by either using too few threads or needing to keep track of too many)
8) If it worked you will now have the kernel in arch/arm/boot/zImage
this can be injected into the boot.img (as the kernel, using an existing ramdisk) as is
If it failed for your kernel your kernel source may need one of the common patches
9) Building modules
the following will prepare the modules in subdirectory mod:
make modules
rm -rf mod
mkdir mod
cp `find ./ | grep .ko$` modules.order mod/
After these commands [if no errors] you can simply copy the contents of mod/ to /system/lib/modules on your device, note it is recommended usually to remove the existing contents of /system/lib/modules unless there is a closed source module required from the previous build despite the new kernel.
[size=+1]Common Patches Required[/size]
If your kernel has not been built for the new toolchain or on cygwin before you may require some of these common patchs: (I've thus far only tested this on my Acer A100/A500 source)
wireless/bcm4329 for GCC-4.6.3:
https://github.com/ezterry/AcerTabKernel/commit/123f32e27e2c74f1c1789ae5d6d5a1c04e1e264c
linux kernel module patch for cygwin (broken elf.h):
https://github.com/ezterry/AcerTabKernel/commit/220db49593cf6b9f3b556e2f4b75b2f6d3ff556c
Error compiling security/smc/bridge_pub2sec.S (I required the cygwin elf patch and this patch to build the Franco galaxy nexus kernel)
0001-Fix-build-error-with-4.6.3-toolchain-smc-0.patch
(use 'git am 0001-Fix-build-error-with-4.6.3-toolchain-smc-0.patch' to apply)
OSX stat patches (fixes errors between GNU and BSD stat):
https://github.com/ezterry/AcerTabKernel/commit/0c49df3cc1a05a0ccd98201511cdc0534aaeb35a
Errors loading newly built modules (modules appear to build cleanly but wont install):
simply add -fno-pic to CFLAGS_MODULE
https://github.com/ezterry/AcerTabKernel/commit/c5ed0fcb014d36936a86ad253f15af43de2f644a
(I can add others here if highlighted to me, and as I find them)
[size=+1]Other Toolchain uses[/size]
The linux toolchain can be used to build android components, however this requires various manipulation to the android /build git repository as currently various other toolchains have hard coded paths into the prebuilt repo. If you intend to incorporate this into your build it may be best to inject the toolchain into your prebuilt repo rather than expect your users to download the links above, ensure to keep the compile notes as it explains how to get the source code to the toolchains)
On cygwin/osx it may also be possible to build android applications however I've not yet tested this as the scripts to make a proper build are complex when attempted outside the android build tree.
Excellent!!! thanks Man!!! Has been looking for one of these
Added in the OSX version of the toolchain (and some related patches)
Also if you are having problems with your modules built with this toolchain a CFLAG fixes it. (see note in common patches)
FINALLY!!! Great Instructions followed them to the T and BAM got my kernel compiled!!!
wow your toolchain is so small, many thanks, just compiled a kernel for my LG P500 gonna test it, thanks again
Bookmarked for testing when I wake up...
I can almost put: "Building under Windows is not currently supported." (quote from google), unofficially at least, out of my mind...
I have been spoiled by Windows for far too long I fear, my attempt for this last week at getting Linux setup and building CM9 has been nothing but a complete FAILURE, too many single line entrys for different distributions/package combo's, commands I dont know and cant find because of wildcard portions of them and lack of understanding, and not enough scripts like the wonderful Compile CM9 script someone put up (cant run it because all the pre-req's arent setup).
Good god Ill be jumping for joy if this works tomorrow on WinBlows!
EDIT: never mind, problem solved, what I need to know now won't be solved here
I wish i knew how to go about doing this..
Thanks
Thanks For ........... i Really need It .........
Hammerfest said:
Bookmarked for testing when I wake up...
I can almost put: "Building under Windows is not currently supported." (quote from google), unofficially at least, out of my mind...
I have been spoiled by Windows for far too long I fear, my attempt for this last week at getting Linux setup and building CM9 has been nothing but a complete FAILURE, too many single line entrys for different distributions/package combo's, commands I dont know and cant find because of wildcard portions of them and lack of understanding, and not enough scripts like the wonderful Compile CM9 script someone put up (cant run it because all the pre-req's arent setup).
Good god Ill be jumping for joy if this works tomorrow on WinBlows!
Click to expand...
Click to collapse
If you succeed tell me how to do it in a more familiar way
I get errors regading the processor not being supported?
brfield said:
I get errors regading the processor not being supported?
Click to expand...
Click to collapse
Sorry I can't support devs that have not learned cut copy and paste.
You probably forgot to export some of the environment variables or are just trying to run a arm binary on your PC and or a x86 binary on your arm device.
But why am I guessing? Why don't we know what you tried to run and what the actual text of the error was.. what type of kernel you tried to build, what you are running?
These packages are for developers if you feel like using them its time to learn to how to trouble shoot a problem and write a ticket to explain said problem clearly to others with at least some information to give us a chance to understand.
Sent from my Galaxy Nexus using Tapatalk 2
Great guide. Have the bcm4329 wireless module, so followed the tips and everything compiled and works!
Thanks!
one question,how to compiled android kernel with -O3 optimization?
jxxhwy said:
one question,how to compiled android kernel with -O3 optimization?
Click to expand...
Click to collapse
Um, in general its recommended you don't:
-O3 is not recommended for the kernel as many low level parts require the assembly code generated to remain as is and not be optimized as will be by some of the options -O3 enables thus likely reducing the stability of your kernel.
---
That said the menuconfig has an option to optimize for size (-Os) if enabled else -O2
For other optimization (including tuning for your cpu) you can add them to the CFLAGS_KERNEL/CFLAGS_MODULE in the make file.)
For -O3 like functionality you could add the increment to the line:
-finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftreel-vectorize, -ftree-partial-pre and -fipa-cp-clone
-Ofast is -O3 with -ffast-math as well
If you do build with all the -O3 or-Ofast options ensure you test the kernel for stability and run some benchmarks. (as it may not actually be faster depending on the cache misses)
The first option I'd start pruning was the one mentioned in my reference below -fgcse-after-reload.
If you really insist on -O3 rather than just adding the optimization you want that are not in O2,it can be added also in the Makefile where the configure flag is checked and its added to KBUILD_CFLAGS
Obviously all and any of this is at your own risk, anything that breaks you have to find a way to fix it.
Reference:
Gcc optimize options:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Talk of O3 and the kernel (not android specific)
http://unix.stackexchange.com/questions/1597/compiling-gnu-linux-with-o3-optimization
ezterry,thank you very much!
I want to build cm9 kernel using toolchain 4.6.3.
How to replace the default GCC 4.4.3 to 4.6.3 version?
BTW,I use the way -- make bootimage
jxxhwy said:
ezterry,thank you very much!
I want to build cm9 kernel using toolchain 4.6.3.
How to replace the default GCC 4.4.3 to 4.6.3 version?
BTW,I use the way -- make bootimage
Click to expand...
Click to collapse
If you are asking in a cm9 build tree.. its a pain, best is to update the cm kernel makefile to point the build chain temporarily.
If you mean just to compile by hand as described in the op
Once the kernel is compiled find an anykernel update.zip or manually use mkbootimg or fastboot to merge it with the ram disk. Cm9 targets mkbootimg and unpackbootimg (if I'm not mistaken) will build the applications to unpack your current (or the default cm9) boot image and re-create them with your custom kernel built from hand.
Now,I runing script file:
#Let's make sure the environment is clean and ready to compile the kernel
echo "Cleaning house!!"
make mrproper
echo "House cleaned, lets build a kernel!!!"
#
# Lets set the kernel defconfig
echo "defconfig = cyanogenmod_iprj_defconfig"
make ARCH=arm cyanogenmod_iprj_defconfig
#
# Let's build a kernel
echo "Now compiling kernel, go get a soda! "
ARCH=arm CROSS_COMPILE=~/Android/sourcecm9/cm9/toolchain-4.6.3/bin/arm-linux-androideabi- make zImage -j4
#
if [ -f arch/arm/boot/zImage ]; then
echo "Plague has been compiled!!! You can find it in arch/arm/boot/zImage"
else
echo "Kernel did not compile, please check for errors!!"
fi
but,I got some error output:
/home/xxx/cm9/toolchain-4.6.3/bin/arm-linux-androideabi-ld: cannot find usr/initramfs_data.o: No such file or directory
thanks again!!!
I think that means there is an issue with your config..
Most android kernels require initramfs, but don't specify a file, as its provided by the bootloader.. However in your case it is trying to embed it into the kernel.
Sent from my A500 using Tapatalk 2
ezterry said:
I think that means there is an issue with your config..
Most android kernels require initramfs, but don't specify a file, as its provided by the bootloader.. However in your case it is trying to embed it into the kernel.
Sent from my A500 using Tapatalk 2
Click to expand...
Click to collapse
issue has been resolved by myslef.Thanks for your time.
~~~~~ Latest release
A500 - V1.0.1 (first stable release)[Size=+1]
ezT20-v1.0.1-a500_S.zip
MD5: 73e25f9970dc5f34d863a2c7155968d2
[/SIZE]
**Please remove all undervolting and overclocking before installing, as different kernels will use the CPU differently, This may require you thus to change the OC/UV levels to be stable with this kernel.
While plenty of work has gone into ensuring this kernel was fit for use: I take no responsibility for any problem the use of this kernel may cause, and/or loss of data if you fail to backup your data before installing it. Proceed at your own risk
Notice: This kernel will only operate on an unlocked ICS bootloader, for the a500 this is the patched bootloader
A500 Installation: : simply flash the zip from recovery, this will extract and replace the zImage (linux kernel) from your current rom; and leave your existing ramdisk unchanged.
A501 Installation: :Your ICS rom requires to load the new simdetect_switch.ko module on boot, if your rom dose not have support for this, but has support for init.d scripts please first install the patchkit ezT20_a501_patchkit_S.zip MD5: 617f558555c13d215103cd3669d3c009, (This kit only includes the init.d script to load the simdetect_switch module if it exists, and doesn’t include the actual kernel or modules)
After the patch kit is installed (or if it has been previously installed/is part of your rom) you can flash the a500 zip above to install the kernel + related modules.
CM (9 and 10) installation Install per your device above, then install the audio patch init.d scripif you have audio problems: ezT20cmaudio_patch_S.zip MD5: 26251900115b0ca433f26f4d95e7f269 (see this post for more information)
Are you an A100 user? you are in the wrong place see here
~~~~~ ICS Kernel Features
- BFQ IO scheduler (details here)
(BFQ is now the default scheduler, previously was noop)
- Lulzactive CPU governor (by tegrak with a500 modifications by myself)
(Interactive will be the default governor for most roms, as defined on the ramdisk, however lulzactive is recommended)
- Max OC speed: 1504MHz (default 1000MHz)
- Min OC speed: 216MHz (default 216MHz)
- Fixed voltage tables to allow OC on devices previously unable to on A500-OCTestV3 and A100-OCTestV1
- initial 3g support thanks to patches from Vash (v1.0.0 - a501) .. switched to acer's code in v1.0.1 (a501/a101)
- ability to disable acer audio settings (v1.0.1)
~~~~~ Kernel Notes/Warnings
** A specialized lulzactive configuration program can be found at: https://play.google.com/store/apps/...1bGwsMSwxLDMsImNvbS50ZWdyYWsubHVsemFjdGl2ZSJd
(note setCPU will also let you change the values, I only mention tegrak's app as it may make it easier to understand what is being changed)
** The kernel ought to work in place of the stock ICS kernel, roms requiring special kernels may not function with this kernel
** de-odexed roms may have graphical artifacts that are made more serious by this kernel, civato and I have been working on a build.prop tweak to re-generate odex like dex files on de-odexed roms to solve this
** Voltage display may not be accurate (a rework of the UV logic is planned) note UV offsets are accurate.
The following is using the following:
* My Near stock rom
* My disk-io tweak for the rom
* lulzactive Min: 216 Max 1504
* BFQ scheduler
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
~~~~~ Kernel History
This kernel is the continuation of the Overclocked Test kernel, originally posted for the A500 here and subsequently for the A100 here
~~~~~ Credits
Thanks to:
* richardtrip - original OC and MIN/MAX code
* tegrak - for lulzactive
* civato - for being a willing advanced tester
* Bobg1231, Metallkasten, pio_masaki, Moscow Desire - additional testers
* Vash - A501 3g modem patch set
* Acer/NVidia for providing the source to our devices
* The countless number of people that have created the linux kernel in the form it is today
~~~~~ Release Build list w/ source links
v1.0.1 ezT20-v1.0.1-a500_S.zip
MD5: 73e25f9970dc5f34d863a2c7155968d2
Github: https://github.com/ezterry/AcerTabKernel
Tag: ezT20_kernel_v1.0.1
Tarball: https://github.com/ezterry/AcerTabKernel/tarball/ezT20_kernel_v1.0.1
v1.0.0 ezT20-v1.0.0-a500_S.zip
MD5: 007f00e576bf82f9439f9567685dd255
Github: https://github.com/ezterry/AcerTabKernel
Tag: ezT20_kernel_v1.0.0
Tarball: https://github.com/ezterry/AcerTabKernel/tarball/ezT20_kernel_v1.0.0
NET-USB modules [Experimental] for this version: http://forum.xda-developers.com/showpost.php?p=27887611&postcount=52
v0.9.9 ezT20-v0.9.9-a500_S.zip
MD5: c43844babbd96ab43399a100d74d60de
Github: https://github.com/ezterry/AcerTabKernel
Tag: ezT20_kernel_v0.9.9
Tarball: https://github.com/ezterry/AcerTabKernel/tarball/ezT20_kernel_v0.9.9
~~~~~ Change Log
v1.0.1
*) Import of acer's 3g code [A101 and A501]
*) audio updates to better work with CM roms when cm audio patch is applied ezT20cmaudio_patch_S.zip MD5: 26251900115b0ca433f26f4d95e7f269
*) Allow lower min-voltage
v1.0.0
*) cleanup graphics logic with more patches from the nvidia tegra test kernel (and other patches to prevent the graphic under-runs causing screen flashes on some roms) [applies to all devices]
*) modify lulzactive (yet again) to attempt to stem a rare deadlock .. frequently resulting in a SoD overnight on my tab (probably not most peoples constant SoD problem) [applies to all devices]
*) Add Acer A501 patches for 3g modem [applies to A501]
*) fix some touch events on the A50X caused by the a100 patch set rolling back the a500 touch driver, the touch drivers are separate so this ought not impact the a100 [a50x only]
v0.9.9
Initial release, providing some bugfixes and new features to the previous OCTestV3
**build instructions in second post
Developers Corner
~~~~~ Background
As you may know the linux kernel is considered Free Software under the GPL.
To the creators of the GPL licence this means:
The Free Software Definition said:
“Free software” means software that respects users' freedom and community. Roughly, the users have the freedom to run, copy, distribute, study, change and improve the software. With these freedoms, the users (both individually and collectively) control the program and what it does for them.
Click to expand...
Click to collapse
Full text here
This means when Linus Torvalds changed the licensing from "Non-Comercial" use to the GPLv2 he was no longer preventing the kernel from being used in commercial products (as is obvious by its use on all android devices) However requested that anyone who received a copy of the software, get or be offered a copy of the source as well, and to be allowed to modify that source and distribute those changes to someone else, with the only restriction being they must also provide the source so the next person can also make changes.
Mind you this dosn't mean free software is actually free. Countless hours of hard work by countless people make the kernel what it is today.
While we all must provide the source, if something isn't already in the kernel that you want you have only the following options:
1) find someone willing to make the change
2) pay someone to make the change
3) roll up your sleeves and make the change yourself.
Also note one makes you give away changes you write to the linux kernel, you only must give the source to those who already have the binary.
~~~~~ This Guide
This guide will help you build the kernel yourself on your computer from source, this is in hopes that you may take an interest in how both the build system, and kernel its self works.
Instructions will be primarily focused on both linux, and cygwin users; however osx users may also be able to follow this guide with only minor modifications.
If you do make changes you think the public is interested in I will also be happy to review and potentially include it in my future builds, remember however while its polite to credit me for the codebase provided, you may always distribute you modified versions of the kernel as long as you adhere to providing the source per the GPLv2 to those you distribute it to.
~~~~~ Getting Started - Downloading The Toolchain
The toolchain is the compiler used to convert the 'C' code of the kernel into the arm instructions red by your device.
To build this kernel I use a custom android toolchain based on gcc4.6.3;
Pre-built binaries are available for x86 linux, cygwin, and osx:
1) Download the one for your platform
x86 Linux: toolchain-4.6.3.tar.bz2 (Sha1: c8c57aba6ad92e9acddf29ba
Cygwin: toolchain-4.6.3.cygwin.tar.bz2 (Sha1: 6947e1c1ba95195019f542eb8ba0708667b63eca)
OSX: toolchain-4.6.3.darwin.tar.bz2 (Sha1: 9a977f0672863fdd9501383a6ad1e30723281f
Additional details about these files are on my Android Software post:
http://forum.xda-developers.com/showthread.php?t=1686310
All users may wish to look over the cygwin building requirements there to ensure there system has the required packages.
Other information on the post will include information about retrieving the source to the tool chain its self and another overview of building android kernels in general, and not just this specific Acer kernel.
2) Now that you have the toolchain you want to extract it; this can be done anywere but I recommend for the sake of this guide in your posix home directory
this is done by running at your posix prompt (cygwin terminal in windows normal terminal in linux/osx)
Code:
mkdir -p ~/android
cd ~/android
tar -xjvf </path/to/>toolchain-4.6.3.cygwin.tar.bz2
substitution '</path/to/>toolchain-4.6.3.cygwin.tar.bz2' with the file you downloaded above
all versions will extract then to '~/android/toolchain-4.6.3/' all the files required to build arm binaries
~~~~~ Getting the source code
This can be done many ways, if you want to build a specific version the tarball may be easiest, however it is recommended that you use the git revision control software if you wish to make changes, as this helps keep track of the changes, and publish them on services such as github. (in addition its easier for other people to take the changes into there own work without you loosing credit)
3) To get the AcerTabKernel source change directory into the ~/android directory used to make the toolchain
Code:
cd ~/android
4) run the command to fetch a copy of my git repository
Code:
git clone git://github.com/ezterry/AcerTabKernel.git
5) change into that directory
Code:
cd AcerTabKernel
~~~~~ GIT only, switching code views
Once you have the source code you can always refresh it with git fetch origin, however more work is required to update the local files
Option A: following a branch (recommended if you want the latest source)
6.A.1) run 'git branch -a'
you will likely see the following:
master - you local version of the master branch
remotes/origin/HEAD -> origin/master -- indication master is the default branch
remotes/origin/master -- the remote version of master (as of the last 'git fetch origin' or 'git pull' command)
remotes/origin/tegra_overclock -- the remote version of tegra_overclock (as of the last 'git fetch origin' or 'git pull' command)
the two branchs of interest are as follows:
master - the acer A100/A500 source including my enhancements w/o overclocking support
tegra_overclock - the full enhancement list with overclocking
6.A.2) Create a local version of tegra_overclock
run:
Code:
git branch tegra_overclock origin/tegra_overclock
6.A.3) Switching branches
you can switch between the branches by calling
Code:
git checkout <branch name>
so if you want to build this kernel you will call:
git checkout tegra_overclock
Option B: retrieving a specific tag
6.B.1) If you want the code to a specific kernel you can force the checkout of a tag
Code:
git chekout -f [color=gray]<tagname>[/color]
so for the v0.9.9 you can run
Code:
git checkout -f ezT20_kernel_v0.9.9
This will fetch the code, however you local branches will not be updated if you make changes, see on screen note for details
~~~~~ Building the kernel
Once you have the code you can build the kernel (or make other changes first)
7) Set up your build enviroment
Most steps above need not be done any time you make a change; however every time you want to build from a new terminal you must set up that terminals environment as follows
A) add the toolchan to your path:
Code:
export PATH=$HOME/android/export PATH=$HOME/android/toolchain-4.6.3/bin:$PATH
B) run the following commands to prepare the cross compiler from within the directory with the code (ie 'cd ~/android/AcerTabKernel')
Code:
export ARCH=arm;export CROSS_COMPILE=arm-linux-androideabi-;export KERNEL_DIR=`pwd`
*note I make this one line to make it easier to copy and paste all at once
8) Now that the enviroment is set up we can configure the kernel by running
For A500 Kernels:
Code:
make picasso_defconfig
For A100 Kernels:
Code:
make vangogh_defconfig
This will grab the default configuration for the device (same as /proc/config.gz on the running kernel) in the source tree this is arch/arm/config/picasso_defconfig or arch/arm/config/vangogh_defconfig
9) if you want to change the config (add/remove modules and components or change the kernels name):
Code:
make menuconfig
this will provide the kernel configuraiton gui that allows you to update the many kernel options including adding modules.
10) build the binary kernel
Code:
make -j5
you should replace the 5 in -j5 with the number of CPU cores in your computer + 1. 5 is ideal for a quadcore CPU.
If the number is lower/higher the kernel will take longer to build. (slightly higher however will have minimal impact)
11) prepare the modules (makes sure the modules are ready for use, they are built in the previous step)
Code:
make modules
~~~~~ Packaging the kernel
At this point you can find the kernel in arch/arm/boot/zImage and if you search for files ending in *.ko you will find all the built modules
However here I will describe creating the update.zip installer
Note this may look difficult as the process is mostly manual not automated
12) Download the template (I will assume you are in the directory with the kernel source still)
Code:
wget [url]http://android-git.devnull.name/gh/tepl/acer_kernel_tmpl.tar.bz2[/url]
This template contains the update_binary, unpackbootimg and mkbootimg binaries
In addition it has the ufsd.ko acer stok module (a closed source kernel module used for mounting ntfs disks) the updater-script you will use, and a nfo.prop template
koush is to thank for the unpackbootimg source (unpackbootimg/mkbootimg I built using the A500 Public Recovery source tree, updater_binary is from the stock ICS installer)
13) for future use move the template outside your source directory in case you delete/refresh it
Code:
mv acer_kernel_tmpl.tar.bz2 ~/android/
14) make the update.zip work directory
Code:
tar -xjvf ~/acer_kernel_tmpl.tar.bz2
15) copy over the zImage
Code:
cp arch/arm/boot/zImage acer_kernel_tmpl/[color=gray]<kernel_name.zImage>[/color]
the kernel_name can be any name you wish to call the kernel
16) copy in the modules
Code:
cp `find | grep ko$ | grep -v ufsd` zImage acer_kernel_tmpl/system/lib/modules/
17) copy in modules.order
cp modules.order acer_kernel_tmpl/system/lib/modules/
18) edit the nfo.prop
update the values as per the comments, this will control the displayed output during install
as well as allow you to specify any name for the zImage to be installed without
touching the edify script
19) generate the installer zip
Code:
cd acer_kernel_tmpl
zip -r ../kernel_install.zip .
cd ..
now kernel_install.zip can be flashed from clockworkmod (as an unsigned zip) or you may optionally sign the zip now to publish
~~~~~ What next
What next is up to you, there are many source files to look at some never used for our devices.. and many that I've never looked at.
One important thing however is learning the basics of git revision control, and how to maintain your local mirror and keep it in sync with the version I have on github.
Other interesting git features include remotes allowing you to compare source from other kernel repositories and even cherry-pick individual commits from other users.
If you know how to code, learning this isn't difficult so off to 'git help' and google you go
Hi there Terry - looking forward to giving this a try. Also, thanks for going above-and-beyond on the GPL thing and giving really detailed instructions - I've never compiled for Android in my life so it made interesting reading.
Hey
Can wé flash it with cwm or wé néed es nvflash
Thank s
rayman95 said:
Hey
Can wé flash it with cwm or wé néed es nvflash
Thank s
Click to expand...
Click to collapse
Look what I found in the OP
Installation: simply flash the zip from recovery, this will extract and replace the zImage (linux kernel) from your current rom; and leave your existing ramdisk unchanged.
Click to expand...
Click to collapse
But if you are using it on the flexreaper rom , please use the patch from that thread .
It has got this kernel in it but also the tweaked build.prop.
Read OP of this thread regarding de-odexed roms.
civato said:
Look what I found in the OP
Click to expand...
Click to collapse
To be fair I added that line after reading the question and bashing my head..
(anyway nvflash really has no idea what to do with raw zImage files.. as that is all that is in the zip; the boot.img that needs to be flashed to your device also requires a ramdisk.. as indicated now in the op the update script extracts the one currently installed on your tab to generate a full boot.img with the new kernel)
ezterry said:
To be fair I added that line after reading the question and bashing my head..
Click to expand...
Click to collapse
ssssssssst nobody needs to know
I'll try to make a clean patch for A501 support. For now it's a mess =)
vache said:
I'll try to make a clean patch for A501 support. For now it's a mess =)
Click to expand...
Click to collapse
well if you followed my commits this last week or two.. things didn't quite go as cleanly with any of these other patches as I'd hope either.. (what 5+ commits trying to iron out issues in lulzactive.. it really didn't want to play well with interactive in the same kernel build.. and these are all ones I thought worked.. pushed to github..then needed to edit.. if it didn't work before I pushed to gh I'd have modified the commit)
Anyway looking forward to it as I know some people are interested.
I am curious about the lulzactive governor ... it isn't something pulled out of little finger like smartass governor, right (and full of crap, such as "sleep frequency")?
Skrilax_CZ said:
I am curious about the lulzactive governor ... it isn't something pulled out of little finger like smartass governor, right (and full of crap, such as "sleep frequency")?
Click to expand...
Click to collapse
Smarass and lulzactive are based on googles interactive, and really don't have much more overhead just more tuneing.
Sleep frequency is screen off frequency.. (useful if music is running or a background task to not OC, default is the 800mhz level.. lower is prob not wise since it will only be this high if something needs the cpu..) if your tablet is actually asleep its in suspend to ram mode and the cpu is off.. (at least until a wake lock fires or you push the power button) .. prob the most useful state of this is when I have my computer attached by usb preventing the full sleep.. but the power wire is not.
otherwise its a more tuned version of interactive. Allowing tunable quicker ramp ups or slower ramp downs.. I'm just using my own pre-tuned defaults ... edit: it ought to be noted I've also added a super ramp up if the inc_cpu_load is <91% (default value is 75%) and the current cpu utilization is > (100 -((100-inc_cpu_load)/4)) .. (94% with inc_cpu_load=75%) to ramp to max speed and not the ramp up interval of 2 speed steps (as will still happen if the cpu is between 75% and 93%)
Times in state shows a good balance of speeds as needed, and the device is responsive unlike say on demand.
The biggest problem with all the interactive based governors is how they intercept kernel idle .. pm_idle global hook.. replace the function and call the original.. until you start having more modules being enabled and disabled until the pointer is pointing somewhere random and your system crashes.. switch all of that to a register/unregister system based off the one in x86_64
I see, so just some tune.
ezterry said:
if your tablet is actually asleep its in suspend to ram mode and the cpu is off..
Click to expand...
Click to collapse
Yeah exactly ... that's why I said "full of crap, such as sleep frequency".
SoD issues
EZTerry -
I have gotten SoD with nearly all ICS kernels that have been released, both from Acer OTA and with Flexreaper and yours. The only one that I do NOT get any SoD from is the .022 pre-release one that Civato put up on one of the FR builds a while back. Since you seem to be one of the resident experts on kernels for the A500, do you have any idea what differences exist between the .022 build and the current ones, including your OC ones, that could possibly be contributing to the SoD?
For instance, I loaded the latest FlexReaper Extreme Rev 4 (which uses your latest OC kernel) and got peristent SoDs. I flashed back to the non-OC kernel (to get the normal modules back) and then loaded .022 from a flashable copy I had kept. I haven't had any SoD since. No OC, of course, but at least it's stable...
I saw your post about sending you the logs. Still plan to try that, but for now I'm happy with a working tablet.
BakaNeko59 said:
EZTerry -
I have gotten SoD with nearly all ICS kernels that have been released, both from Acer OTA and with Flexreaper and yours. The only one that I do NOT get any SoD from is the .022 pre-release one that Civato put up on one of the FR builds a while back. Since you seem to be one of the resident experts on kernels for the A500, do you have any idea what differences exist between the .022 build and the current ones, including your OC ones, that could possibly be contributing to the SoD?
For instance, I loaded the latest FlexReaper Extreme Rev 4 (which uses your latest OC kernel) and got peristent SoDs. I flashed back to the non-OC kernel (to get the normal modules back) and then loaded .022 from a flashable copy I had kept. I haven't had any SoD since. No OC, of course, but at least it's stable...
I saw your post about sending you the logs. Still plan to try that, but for now I'm happy with a working tablet.
Click to expand...
Click to collapse
But how is ezterry going to know what is differents or how can he help if he doesn't have a logcat.
If ezterry needs to test every rom situation we need to start paying him for giving us better support then we will ever get from acer.
So please provide logcat.
PS:
f is looking real good m8.
will report to you tomorrow .......
civato said:
But how is ezterry going to know what is differents or how can he help if he doesn't have a logcat.
If ezterry needs to test every rom situation we need to start paying him for giving us better support then we will ever get from acer.
So please provide logcat.
PS:
f is looking real good m8.
will report to you tomorrow .......
Click to expand...
Click to collapse
Well, now that I have a stable working build, I can do a backup and then play with the new kernels to get the logcat. I was just so happy to get a working build that I hadn't considered my next step.
I'll play some more when I get home from work since I can't have my tablet in my office.
You wouldn't care to provide a step by step guide of how to get the logcat info would you? I know it requires adb, but not much else. Also, in another post you mentioned getting the last_kmsg (or last_kmesg - I forget). How do we get that?
Thanks. I appreciate the help.
BakaNeko59 said:
EZTerry -
I have gotten SoD with nearly all ICS kernels that have been released
Click to expand...
Click to collapse
SoD is simple to understand in these terms:
Think of your computer or laptop, you request it to suspend to ram or sleep depending on your OS
It does so, turns into the low power state but is otherwise off, and waits for your return.
When you try to turn the computer on it attempts to wake up but then instead crashes.
This is exactly what is happening, android noted nothing was running and suspended the tablet to ram, either was woken up by you pushing power or a timer the operating system set when it went to sleep.
However before fully starting again the system crashed.
In development of the kernel sometimes I run into such problems with bugs in the oc code, or undervolting too far.. but once I call a kernel stable-ish it can usually last the day with many sleep/wake cycles.. can't say there is never an odd sod but its not common.
The question for you the is: what when wrong.. the easiest way to see is the kernel log of the now crashed kernel.. this requires looking at the /proc/last_kmsg file but this is a little tricky if you needed to force power off the tab (the log is stored in ram thus is completely wiped after 8-10 seconds of the tab being powered off.
When it does exits adb pull can grab the file as soon as the android animation begins.
Sent from my Galaxy Nexus using Tapatalk 2
Does this kernel have cifs module built-in? I can't try by myself right now, my a500 is in vacation at acer's repair facility.
ezterry said:
.
The question for you the is: what when wrong.. the easiest way to see is the kernel log of the now crashed kernel.. this requires looking at the /proc/last_kmsg file but this is a little tricky if you needed to force power off the tab (the log is stored in ram thus is completely wiped after 8-10 seconds of the tab being powered off
Click to expand...
Click to collapse
Does the last_kmsg ONLY exist if there's a fault registered or does it get updated regularly during operation? In other words could I create a continuously running script (for debugging only of course) that copies the last_kmsg file to another location before the system actually crashes? Then when it enters sleep the last file copied would have the information you need? Or is there a way to execute a script early enough in the boot process to copy the file during that first 8-10 seconds of power up so that it is easier to acquire?
Or how about a batch file that simply loops the command "adb pull /proc/last_kmsg last_kmsg" continuously on my PC? If the file doesn't exist it doesn't get copied - if it does exist it gets copied, and if the system crashes and doesn't respond, the last file copied should exist either before or after I manually power off and on the tablet. Hmmmm - guess I'll give it a try...
Sorry - just thinking out loud now
Thanks.
Sent from my A500 using Tapatalk 2
so is it as easy as flashing in CWM over any ics rom?
can i flash this with AOKP??
thank you =]
BakaNeko59 said:
Or is there a way to execute a script early enough in the boot process to copy the file during that first 8-10 seconds of power up so that it is easier to acquire?
Click to expand...
Click to collapse
What do you mean the file is there until reboot if the log data is found, so there is no hurry to pull it off the device.
The logdata is only stored in ram.. so if you power off overnight or while microwaving a frozen dinner.. when you turn the tab back on no data will remain.
Ram however will hold its values for a short time without power however, if you needed to force the tablet off by holding power for 5 seconds you have under 10 seconds to power back on the device if you wish to see any of the log. (and you need to leave it off 3 seconds or it will ignore your pressing power.)
Second thread in a week. Read on, young dev, for you are about to enter a world of Android goodness soon.
WHAT IS A KERNEL?
A kernel, as explained by viper001 in his thread, is the software layer between the ROM and the hardware. It contains the crucial init process of the boot sequence. So an Android phone with a faulty kernel may mean a very expensive paperweight. But fear not I have compiled several kernels for my phone (released a few of them too) and I have never ever bricked my phone (not even a bootloop, strange right?).
WHY THE NEW THREAD AND WHY YOU SHOULD COMPILE A KERNEL?
viper001's thread is pretty outdated (it was published in 2010, it's nearly 2013 now) and uses the FXP source (which is also pretty old). Therefore if you compile a kernel following that guide, you'll only be able to use it with FXP ROM (which is almost ancient by now). That is why I decided, after considering Rohin's suggestion, to write a new kernel building guide, for members who wish to step into the dev world by compiling a kernel. Keep in mind, neither the XDA-ians nor I am to be held responsible if you do brick your phone (even if you pee on it due to sheer excitement, though I am pretty sure you'll handle it....LIKE A BOSS).
THE ACTUAL GUIDE
Okay so you want to compile your kernel, huh? Well, you're gonna need some packages and toolchains and sources and blah blah. In short these are the requirements:
1. An Ubuntu build (Linux Mint will do too but I haven't tried using it) on a fast computer (preferably a quad core but a dual core 2.4GHz will do too, 2GB of RAM) or a virtual installation (Google installing ubuntu on vbox).
2. Some packages that you can get by typing this in the Terminal:
sudo apt-get install git unrar libncurses5-dev qt3-dev-tools
3. A kernel source
4. A toolchain
5. Flashtool in your Windows installation (you must have one)
KERNEL SOURCES AND TOOLCHAINS
nAa GB (L)
nAa ICS (L)
nAa JB (L)
Alfs GB (use master branch; test has problems) (L)
LINARO (L sources only)
LINUX GNU Compiler for ARM
INSTRUCTIONS
Make a folder where you'll be working for the time being. Name it conveniently. Unpack a source there and a toolchain (use the Linaro one, it makes the kernel slightly faster and each of the sources I mentioned is compatible with it). Rename the toolchain folder, and the source folder too, to something simpler. It's better if all this is done without root, because that may screw your Ubuntu installation beyond recovery. Even so I did it in root. You, however, should do it in any place other than root, and make sure you can easily navigate to the place through Terminal.
Now for the tough Terminal bit. Navigate to the source folder and type in this:
export ARCH=arm
export CROSS_COMPILE=/path/to/toolchain/folder/bin/arm-linux-gnueabihf-
This will tell Terminal to build the kernel for the ARM platform using the Linaro toolchain.
Then type in:
make xxxx_shakira_defconfig
Where xxxx is the part of the name before _shakira. Check the /arch/arm/configs directory for either semc_ (for Alfs kernels) or nAa_ (for nAa kernels). Or you can make your own defconfig if you're up to the challenge.
Then type in:
make menuconfig
This will display a GUI version of your defconfig. Edit anything you want to there or directly in the defconfig.
Then type in:
make -j#
Where # is the number of cores your CPU has + 1.
If all goes well, you should have your kernel image. Grab the Image file form /arch/arm/boot.
You do have Windows installed, right? Good, because you're gonna need it now. Download the bootloader unlocking tool (not Flashtool, the one posted by the_laser).
You have to copy your Image file and a ramdisk, check my other guide, to the sinTools folder of the bootloader unlock tool. A suitable ramdisk, not a GB one for an ICS kernel and vice versa. Then rename the Image file to image and double-click on example_build.cmd. You should get a result.zip. Exatract it and rename result.sin to kernel.sin. Copy it over to a folder and place a loader.sin from a working kernel there too. Open up Flashtool. Go to Advanced > Bundle creation. Navigate to the folder and select both files and move them over to the right-side (by clicking the > button). Give it a proper name and branding and click OK. FLASH! FLASH! You are done with your kernel. First ever, huh? Wish to know more.
If your build failed, type in
make mrproper
or
make clean
Coming soon, TIPS AND TRICKS and more.
P.S.
It is pretty obvious that I'm not a RD, or any D for that matter, this guide may have petty mistakes. Therefore I request any member to let me know if there are any mistakes should he/she find any.
Stay safe and pray that your PC doesn't explode while you're doing this.
If any of the Forum Mods are reading this, you may wonder why I posted this when there already was a guide. viper001's thread is a bit outdated although some users have compiled kernels following it. Therefore to help users who are quite new to this, I wrote this. I sincerely hope I do not get warned for posting a guide twice, just to help people compile newer kernels.
NEITHER THE XDA-IANS NOR I AM TO BE HELD RESPONSIBLE FOR ANY DAMAGE THAT THIS MAY CAUSE TO YOUR PHONE. YOU ARE SOLELY RESPONSIBLE FOR WHATEVER YOU DO TO YOUR PHONE.
But do ask for help if you need it.
EDIT: You can also use the zImage file (you have to rename it to image) as pilu1978 said in his post (check second page and thank him). If you use this, you can attach a larger ramdisk.
COMPILING WiFi MODULES
After you compile a kernel, you need to compile a set of WiFi modules for the kernel. Otherwise your WiFi won't turn on and when you check in Terminal Emulator, you'll get blah blah.ko magic version errors. So after every compile, you also need to compile your WiFi modules.
For nAa based kernels, all you gotta do is issue the ./build_wifi.sh command right after compiling your kernel. It'll result in 3 files in the source's parent folder: tiwlan_drv.ko, tiap_drv.ko and sdio.ko. You have to copy these files to the ramdisk's modules folder, replacing the ones already there.
For nAa .32 kernel, you don't have to do anything. Just grab the following modules:
net/compat-wireless/net/mac80211/mac80211.ko
net/compat-wireless/drivers/net/wireless/wl12xx/wl12xx_sdio.ko
net/compat-wireless/drivers/net/wireless/wl12xx/wl12xx.ko
Thanks to @btisserand and @pilu1978.
For alfs based kernels, I have no idea. You can ask alfsamsung like I did. I tried it using his method and failed. However I tried copying the vendor_ti_wlan and the build_wifi.sh files from nAa's source to alfs' source and it worked, just once. I couldn't test the modules myself but my tester said the kernel didn't even boot o_0. Therefore I find it safer to stick to the nAa kernel source. But even if you do try with alfs and somehow manage to succeed, do post how you managed to compile it.
EDIT: Thanks to Daveee10, you now have another source for the WiFi modules. Download this as a zipball and extract in Ubuntu. Then execute nAa's build_wifi.sh script in Terminal and you should have the modules. Oh and if you get any permission denied error just chmod it. It works for me.
Next post covers TIPS AND TRICKS.
TIPS AND TRICKS
So compiling a kernel, a bland, vanilla kernel is pretty mainstream. You want more tweaks. That's up to you to find out how you're gonna manage that. All I can do is help you with some things that'll make the kernel your very own, your precious.
Changing the name of the kernel...like completely
You want to change the name of the kernel like
xxxxx
[email protected]#1
[TIMESTAMP]
The xxxxx in the first line can be changed in the defconfig or in the menuconfig (easier). Go to General Setup. Then scroll down to the KERNEL_VERSION line (in menuconfig). Then change the name to anything you like (for example, X8-kernel).
The [email protected]#1 can also be changed. Go to /source-folder/scripts and open up the mk_compile.h file. Scroll down to line 66 and change the word within inverted commas to anything you like (for example, X8). Then in the next line, change the word within inverted commas to anything you like as well (for example, XDA).
After you flash your compiled kernel and go to Settings > About phone, you'll see
X8-kernel
[email protected]#1
[TIMESTAMP]
I'm not sure if you can change the TIMESTAMP.
Editing CPU freqs
Editing CPU frequencies via kernel is also pretty easy (thanks fotak-x for the suggestion).
Go to /arch/arm/mach-msm and open up acpuclock.c.
Scroll to line 202 (the line which says "7x27 with GSM capable modem PLL0 and PLL1 swapped" or something) and just below that you'll see the frequency table which also has the GPU frequencies (??)
The value after { 0, is the CPU frequency, the one you want to change.
You can delete any frequency that you don't use (19MHz and so on) but don't delete 600MHz or add any beyond 864MHz. No X8 will ever go beyond that without freezing up.
The values just before the last number are the voltage units (ranging from 1 to 7). You can experiment with that too but it's better not to.
If you do not know what you are doing, please do not attempt this.
Adding/Deleting I/O schedulers
First look at this commit from DooMLorD: https://github.com/DooMLoRD/Xperia-...mmit/0ae625f7561c559d4933284f489733bf5eb66e96
I'm pretty sure you understood what you gotta do. If you still didn't, read on.
What Sir DooMLorD did was change some lines in the Kconfig.iosched of /block directory to add the Simple I/O scheduler. Then he edited the Makefile to include the building of SIO. The most important thing he did was to make a new file and paste the code that is the script that tells SIO what to do, basically it's core ingredient. You have to perform similarly and change the defconfig to include the I/O scheduler.
Deleting is way simpler than that. You just have to write n after the line in the defconfig where the inclusion of the scheduler is mentioned.
50% FPS-uncap in ICS (and JB?) kernels
It's pretty obvious that I'm referring to the nAa-ICS kernel source. Navigate to the arch/arm/mach-msm directory and open up the board-delata.c file.
Go to line 1915 (the one that begins with panel_data->panel_info.lcd.vsync_enable). Change the value to FALSE. This disables HW vSync.
Then go to line 1999 (it also begins with panel_data->panel_info.lcd.vsync_enable). Change this value to FALSE as well.
Compile the kernel as you would normally. Flash to see a slight increase in performance, and a massive improvement in gaming.
Thanks to pilu1978
That's it for now. Will be updated soon.
CREDITS in no particular order
-viper001
-nobodyAtall
-alfsamsung
-djnilse
-Daveee10
-CyanogenMod team
-pilu1978
-RohinZaraki
-fotak-x
-DooMLorD
-paxChristos
-Google and the Android team
is it possible to compile it from stock kernel?
Thanks sgt may try compiling a kernel just for my ROMs
cool
@fotak-x
yes you can download the stock sources and compile it but it's a little complicated. and all kernels are basically improvements over the stock kernel, so in a way you are compiling a not-so-stock stock kernel.
Thread updated. More tips and tricks now.
Some additions
About the compiler (arm gcc). Today everyone prefer linaro. After a lot of testing, I can say: NO real performance differences between the different compilers (tried google/codesourcery/linaro with lot of versions between 4.4.x and 4.7.x series). Sometime the older is better. The linaro gcc contains optimized libgcc for each instruction set, but we are on the bottom of the list, without the armv7 extensions, extended float unit (thumb-2) and vector processing unit (NEON) the linaro gcc can't give real boost for our phone.
About the cpu frequencies: yes, possible to add/remove/modify these values, but without enough knowledge, better if you not do anything. You use an android phone, so you must know, your best friend: google. Use it. And try to understand how to generate the cpu freqs. Learn about the PLLs, their values, dividers, bus frequencies (axi, ahb, etc...) before start to play with frequencies. You can't set directly the gpu freq, in the msm7x27 SoC series the gpu freq depends on the axi clock (can't work in async mode). Modify the VCC levels, bus frequencies the easiest way to make the phone unstable.
About the wifi modules: you can use the wifi drivers from nAa sources if you want to compile modules to alfs kernel. Or you can find the tiwlan1271 driver sources in the cyanogenmod source tree too. If not working, or you can't compile, try another compiler, or other sources. If you successfully build the modules, you NOT must recompile it after a new kernel build. If you change the kernel versions (2.6.29.xx-xyz) you MUST recompile the modules (the wifi modules linked directly to the kernel version).
good addition mate. i never added any freq and that's why i don't know the exact amount it multiplies by at every step. or even if it works that way. and i never succeeded in compiling the WiFi modules for alfs. and yeah there is basically no improvements in terms of performance between Linaro and Codesourcery. Linaro just seems cool and that's why everyone wants to use it. simple as that. that being said, Linaro does indeed work good on ARMv7 devices as you said in your post.
Some additions (again)
Differences between make clean and make mrproper (if you need to clean the sources after a failed build). The make clean command delete the most generated files and builded objects, but keep the .config file (what contains the changes of actual defconfig) and keep enough informations to build external modules. The make mrproper command delete ALL generated files/objects, after this command you need to configure the kernel config again (make blabla_defconfig and make menuconfig for example). If you use alfsamsung sources, never use the mrproper command, because this source not contains defconfigs, only a predefined .config, the make mrproper delete it, and need to extract this file again.
About the Image and zImage: the difference between these files is only one, the Image contains the raw kernel code, the zImage starting with a decompressing code and the compressed image. When build the kernel.sin, you can use the zImage too, just rename to Image. The result is a smaller kernel, you can attach bigger ramdisk. The maximum size of the kernel (the complete kernel.sin) is around 8.300.000 byte. A typical kernel image is around 5,5MB (you can use ramdisks with maximum 2,5MB) the compressed image size is less than 3MB (you can use ramdisks around 5MB size)
As sgt. meow wrote: "Linaro just seems cool and that's why everyone wants to use it." This is the general problem in the development section, every "developer" want to make "cool" things, I think better if they concentrate to make "good" things, instead of making "cool" sh!ts...
Some tips:
If you make a kernel, never post it: based on LATEST xyz source. The latest is relative. Write a correct commit version, if you don't know what is it, need to learn before publish kernels.
To the members who have low bandwidth. Download sources as zipball, it needs less data transfer than a repository sync (when you sync a repo, you download a lot of deltas, additional files too), a typical kernel zipball is around 90MB. This method works with rom sources too (but more complicated, because you need to download and extract manually more than 200 files), for example the minicm7 sources with manual download as zipballs is only 600MB (without the prebuilts what is around additional 700MB).
If you want to be "cool" and use linaro, use the standalone linaro gcc (the arm-none-eabi version) instead of the linaro toolchain (arm-linux-gnueabi version) it will give less compiling errors.
true dat, brother.
and is minicm7 really about 1.3GB in size as zipballs? one more thing i heard (read, probably) that the zImage is the compressed version of the Image with a decompression code. so if we use that, won't booting time be a lil bit slower?
added all your suggestions bro. thanks a lot for helping out. you should apply for RC.
No, the compressed image not give significant slower boot time. All nAa kernels use compressed images, and boot faster than the alfs (the alfs8 use normal image, the alfs9 use compressed).
Yes, the minicm7 source only 614MB if you download as zipballs. For example: the settings app size is 3,5MB if you download as zip, but the git repo is around 90MB (this is an extreme example, with some part of code you can't decrease the download size).
Tips to use this method.
Make the repo init, but not start the sync. Check the default.xml in .repo/manifests, and you can see all needed repo.
You can make download links from this file in this form:
https://github.com/"name value"/zipball/"revision value"
Concrete example:
You see this line:
<project path="bootable/recovery" name="CyanogenMod/android_bootable_recovery" />
The link what you need: https://github.com/CyanogenMod/android_bootable_recovery/zipball/gingerbread
(the most line in default.xml not contains revision, if you not see it use gingerberad for minicm7, or ics for minicm9)
If the download finished, you must extract manually the downloaded file into the "project path". With this example: in your source folder you must make the bootable/recovery folder, and extract the downloaded zip into this folder (warning: the zip contains a folder named in this form - project name+commit number, you must extract the files into the "project path" folder WITHOUT this folder (you need the files INSIDE this folder))
gonna try that soon.
okay so the line has to be edited like this:
<project path="bootable/recovery name="CyanogenMod/android_bootable_recovery/zipball" />
i'm trying it on the MiniCM9 source.
oh yeah android source from googlesource can't be zipballed that way.
sgt. meow said:
gonna try that soon.
okay so the line has to be edited like this:
<project path="bootable/recovery name="CyanogenMod/android_bootable_recovery/zipball" />
i'm trying it on MiniCM9.
Click to expand...
Click to collapse
No.
The correct method for get direct links:
You can see in the default.xml: <project path="external/compcache" name="CyanogenMod/android_external_compcache" revision="master" />
The link what you need:
https://github.com/CyanogenMod/android_external_compcache/zipball/master
The text with puple color: need to write it manually
Text with green color: the repo what you need
Text with blue color: the branch name what you need. Usually you not see the revision in the default.xml, if not exist, use the default branch name (gingerbread or ics, depends on what source needed)
The downloaded file will be this: CyanogenMod-android_external_compcache-cm-7.0.0-0-g5fdea21.zip
Inside the zip package you can see a folder with same name, this folder NOT needed, go inside this folder, and extract the files into the folder what marked with orange colour.
You must do it with ALL project (over 200 files), but you need to download only 600MB, and not need to sync the repo (what is much bigger).
EDIT: You not need anything from google sources if you want CM7 (just the prebuilt binaries, but you can find it somewhere in the minicm nightlies threads, eagleeyetom uploaded it when the aosp servers was unavailable)
EDIT: what about platform/abi/cpp and some others?
sgt. meow said:
EDIT: what about platform/abi/cpp and some others?
Click to expand...
Click to collapse
Please explain it in longer form (I not understand what is the question)
i saw this line in the default.xml
<project path="abi/cpp" name="platform/abi/cpp/zipball" remote="aosp" revision="refs/tags/android-4.0.4_r2.1"/>
this is important. how do i zipball or tarball it?
sgt. meow said:
i saw this line in the default.xml
<project path="abi/cpp" name="platform/abi/cpp/zipball" remote="aosp" revision="refs/tags/android-4.0.4_r2.1"/>
this is important. how do i zipball or tarball it?
Click to expand...
Click to collapse
Okay, understand I checked only the cm7 sources, what not contains codes from aosp servers (only the prebuilt toolchains, but this is available on mediafire servers, eagleeyetom upload it when the prebuilts was unavailable ). So, at this moment no idea how to download code from google servers.
Try this: remove all minicm/cyanogenmod related lines from default.xml, leave only the lines that contains: remote="aosp", and sync the repo with only the aosp code. Or send your default.xml (just copy/paste the contents, and send it in a pm.
sorry for off-topic but @pilu you should be recognized developer
I recently looked into stagefright support in ffmpeg and vlc and found that one of the chore they have is having platform headers to compile against around. Actually, they didn't work for me at all - likely because they were written for one Android version, and I run them on the other. Again, if supporting compilation against even one (random) Android version is a chore, who can expect good support for multiple versions?
To fight against such poor state of things, I'd like to introduce android-platform-headers, which provides headers for all important Android versions side by side.
More info is in the README:
Code:
These are sets of header files extracted from main components of
AOSP (Android Open Source Project), for each main release of AOSP.
Android NDK provided by Google contains subset of AOSP platform
headers which are deemed "external interface" by Google. However,
writing advanced software for Android necessitates access to complete
platform. Many aspects of it change, sometimes drastically, between
releases, so compiling user source code against platform headers for
different releases is required. This project intends to streamline
this process, allowing to access headers for all important Android
releases at once.
In this respect, it is similar to "linux-kernel-headers" found in
many Linux distributions - it allows to compile software without
the need to have hundreds of megabytes (or gigabytes) of complete
kernel (or platform) source code around.
To prepare these headers, all *.h and *.hpp files were extracted
from following AOSP projects:
* system/core
* frameworks/base
* frameworks/native
FAQ
---
Q: Google doesn't recommend usage of non-NDK headers.
A: Who cares.
Q: As these headers don't represent external interface, they can be
changes by vendor of some device.
A: True, so we can figure out what particular vendors work on -
on bringing up innovative products, cutting time to market, increasing
power efficiency, or fragmenting platform and breaking compatibility.
Q: How do I know that headers provided are correct?
A: You are encouraged to verify. Each header project directory contains
.git-org/refs/heads/master with revision of tag from which it was extracted.
Actually, extraction was automatic and script is provided. To easily verify
a particular tag:
rm -rf android-1.6_r1
scripts/fetch-headers android-1.6_r1
git diff
TODO
----
1. Add platform "import" libraries to link with (devoid of code, only with
exported symbols).
2. Similar "implib" jars to link Java code against.
Status update: repo now contains platform headers for the most popular Android versions from 1.6 to 4.2, and started to work on scripts to produce "import libraries" to link native apps against.