Related
Hi,
Because of the need of a bootmanager and the lack of patience to type a hack a lot at the console, I created a ubuntu maverick based build system for arm crosscompiling with a script helps by building kernel, ramdisk, recovery archive, debugging via fastboot and so on. As chroot env it is very flexible, needs not to install something and runs inside all linux distris.
just extract it somewhere onto an ext partition goto the directory and type ./start
in the root of the chroot env is a README file which contains infos where is what. read it before.
it contains three tools
build (a script supports different actions, "build help" shows them)
unpack-boot (extracts a boot image into the actual directory)
unpack-ramdisk (extracts a ramdisk into the actual directory)
Download:
http://www.bisme.net/files/xda/bootbs.tar.bz2
TODO:
the chroot env is still based on a desktop version of maverick and bigger than needed, this will change soon.
PS: Bootmanager is still in work, should finish(as a trivial but working version) in the next days and is the first step to support multiboot different linux installations(also different android versions) on android tablets. But this is another story will get an own Thread here. In the meantime I hope all romcookers out there will have fun with this build system.
WHAT'S IN THE RAMDISK
So anyone who has compiled a kernel (for the X8) or is about to step into the world of developing android awesomeness through kernel building, should know that there are 2 (two) parts to the kernel:
The kernel image compiled from source code, and
The ramdisk
Both are equally important and are inter-dependent; without the kernel, the ramdisk is nothing (unless of course the devs come up with any other use) and without the ramdisk, the kernel is incomplete (again, this may change in the near future).
You (XDA-ians as I like to call you guys), especially those in the X8 sub-forums must have read viper001's kernel building guide. If you haven't, and do not want to read just 4 posts because of your laziness, it tells you how to compile your kernel image. Hah, now you are almost dying to read it. Well go ahead, read it.
Done reading. Well if you followed that guide to the letter (which I am sure many of you haven't), you'll have compiled your kernel with the FXP ramdisk. Now you want to build it from another source. It's pretty much the same process. However the FXP ramdisk won't work with this kernel. Not a chance (maybe a little). You need the ramdisk so you unpack the kernel using DooMLorD's tool (and forget to thank him; go thank him right now) and see a folder named kernel.sin-unpacked. You open it and see a bunch of files that you've never even heard of. You drop the kernel-building project.
This guide will hopefully eradicate that fear, or ignorance (maybe), and cover up what's in the ramdisk.
The parent (or root) directory of the ramdisk folder itself contains a bunch of files and folsers, which also contain more files.
Let's look at the contents in the root directory:
1 “modules” folder – This one is pretty easy. It contains the kernel specific modules that are loaded up at boot.
2 “res” folder – This folder contains another folder named “images” which contains images to be used in the recovery (more on that later).
3 “sbin” folder – Inside this folder are about 200 files (may vary), most of which are responsible for basic functioning of the phone.
4 default.prop – This file contains only a few lines of code that allow adb to run (line 4) and also makes the kernel insecure to give us permanent root.
5 init – This program initializes elements of the android OS and looks at the two following files:
6 init.rc – This file contains generic initialization code
7 init.<machine_name>.rc – This file contains device-specific initialization code.
8 initlogo.rle – This is the bootlogo (not the bootanimation which comes with the ROM).
9 pre_hw_config.sh – This file is executed at boot to get settings like cpu freq and governors just right.
10 recovery.fstab – This file specifies how the different partitions and file systems are to be mounted.
11 ueventd.rc – This file sets user or group (or root?) permissions on /dev nodes. (I got this line from the Internet and have no idea myself what the hell this means o_0).
12 ueventd.goldfish.rc – This file is empty in our kernels. Dunno why, though.
Now for the files in the /res/images directory:
1 icon_clockwork.png – This is the background seen in CWM.
2 icon_error.png and icon_firmware_error.png – These images are displayed on the screen when there is an error. Not sure though as I have never encountered any such error before in my life.
3 icon_firmware_install.png and icon_installing.png – These images are displayed when installing anything via CWM.
4 indeterminateX.png (where X is a number from 1 to 6, both inclusive) – This is basically the animation of the progress bar (the grey stripes moving forwards, or backwards, or both).
5 progress_empty.png – This is the progress bar during the initial stages of flashing anything in CWM.
6 progress_fill.png – This is the progress bar fill.
These are the files in the /modules folder:
1 sdio.ko – This is a file related to WiFi.
2 tiwlan_drv.ko – This is the tiwlan WiFi driver module.
3 tiap_drv.ko – This is the tiap WiFi driver module.
4 x8uv.ko – This is the undervolting module.
5 synaptics_i2c_rmi4_no_dt.ko – This disables dual touch in Synaptics.
6 synaptics_i2c_rmi4_dt.ko – This enables dual touch in Synaptics.
NOTE: I am not an expert.
More to come soon. See you and I hope sincerely that I do not get banned for this.
THE DREADED SBIN DIRECTORY
Going into the /sbin directory, we see a lot of files, the names of each sending shivers down your spine. But fear not, for sgt. meow will help you understand the functions of some important ones:
1. adbd – The file that allows you to use the adb shell. “adbd” stands for “Android Debugging Bridge Daemon”.
2. bootlogo – This file starts the kernel bootlogo (according to some user on the androidcentral forum; just saw a snippet on google search, opened the page and there was no thread).
3. bootrec – This file basically tells a kernel how to boot up a recovery
4. busybox – It lets you run LINUX / UNIX based commands (ls, gzip, uname etc.) that are required for root-level tasks.
5. dmesg – It is the Linux kernel's own logging system and is similar to logcat.
6. fix_permissions – This file applies and fixes permissions on the Android data folders.
7. insmod – This file is basically what is executed when you type insmod /..../../../../ xxx.ko (or similar) to load up the modules. An alternative way to do this is to write the line in hw_config.sh of /system folder (I guess) to load up modules at every boot. Or you could place the modules in the /modules directory of the kernel.
8. killrecovery.sh – This file, as the name suggests, kills the recovery when you exit it and boots into Android.
9. nandroid – The file responsible for nandroid backups.
10. nandroid-md5.sh – This file generates MD5 checksums for nandroid backups to verify its integrity.
11. reboot – This file reboots the phone when prompted to.
12. recovery – This is the recovery binary. For our devices, it is CWM recovery. This file can be changed easily (what I did with oxydo ICS) to other recoveries for this device for that version of Android.
Most of the other files are LINUX / UNIX based commands and some are files the functions of which cannot be explained by me.
More to come soon. Hope you enjoyed it so far.
FILES YOU CAN EASILY EDIT IN THE RAMDISK
There are some files in the ramdisk that can be edited pretty easily. There are also other files editing which means you gotta be RD or gotta have similar talent. Let's not go into that for now. The easy ones are:
1. initlogo.rle - The file that is easiest to edit. Basically you can convert any image to .rle format and replace it. make sure it is the right resolution.
2. /sbin/recovery - You can use recovery from another kernel (for the same Android version)and replace it in yours. You can also compile your own recovery binary by issuing the make recovery command after a successful CM build.
3./sbin/bootrec - You may have to change this when you change the recovery. Just a simple copy paste, that's all.
4. /sbin/rec_input - This file may need changing too when you change recovery.
5. /res/images/.. - Every .png file in this directory can be easily changed to any other .png file. Just make sure the resolutions are right, or else you will not be able to navigate properly in recovery.
6. init.rc - This file is easily changeable but you need to know what you are doing, otherwise you may mess up the boot sequence.
You can have a shot at changing other files, too. Lemme know how it goes.
CREDITS:
1. Allah Almighty (yes I'm a Muslim)
2. All XDA-ians, especially those in the X8 sub-forum for help (and for pressing thanks)
3. The Internet (Google, Wikipedia and Github mostly) for info
4. Me, for spending hours behind this guide.
5. My family, for not disturbing me while I was doing this. LOL
thank you
that is what i'm trying to understand :good:
This is for sure a valuable thread. Thanks for this!!
Sent With My Brains To Yours. Duh.
Nice thread , Captain Meow Meow
Sent from my X8 using xda app-developers app
sbin will take some time to cover but i will try my best.
sgt. meow said:
sbin will take some time to cover but i will try my best.
Click to expand...
Click to collapse
Its good to see that you are working hard...
Keep it up
great thread.thanks
sent from my x8™ using gingerzaraki®
THREAD UPDATED WITH SBIN CONTENTS. OMG. :wink:
Dude, you should make an *updated* Kernel Building Guide with new sources (i.e. alfs kernel or nAa kernel). Old one still uses FXP kernel source and outdated toolchain instead of Linaro.
RohinZaraki said:
Dude, you should make an *updated* Kernel Building Guide with new sources (i.e. alfs kernel or nAa kernel). Old one still uses FXP kernel source and outdated toolchain instead of Linaro.
Click to expand...
Click to collapse
And link to your sources as an example for others..
Banned? And why? This is usefull =))
Sent from my E15i using xda premium
@Rohin
yeah I might
@Elmir
that was a joke
@all
THREAD UPDATED WITH FILES THAT CAN BE EDITED AND CREDITS. :BIG GRIN:
So following a couple of tuts that I've found on the forums I've been able to install debian linux wheezy armhf build on my tablet in a dual boot configuration with it booting off of a second ext4 partition on the microsd card along with getting the drivers/codecs from Linux4Tegra to be installed and somewhat used on debian linux.
What works:
-Wifi
-USB
-Display (doesnt use tegra drivers)
-Buttons (power, vol, rot switch [acts as wifi switch])
-Touchscreen
What doesnt work:
-Bluetooth (Untested but apparently it finds it and sets it up.)
-Audio (Detects it in the kde info center. System Settings program only says that there's a dummy output. Playing any form of audio crashes the program.)
-HDMI (with the Tegra gfx drivers it finds it but says it's disconnected even when connected.)
-Cameras
-GPS
-Motion Sensing
-Light Sensor
With the display, whenever the tegra drivers are used, it finds HDMI (as HDMI-1) and the LCD screen (as LVDS-1) but says that there is no device on the lcd screen. With that being said, it is using the fbdev driver instead which shows pink and/or inverted colors in some instances but at least it shows a gui.
Guides used:
{HOW TO} Native Debian on A500 and building your own rootfs
[BOOTLOADER][DUALBOOT + RECOVERY][BOOTMENU] Patched ICS bootloader V8 (07/06/2012)
[Dev] Native linux on Iconia
Requirements:
-an A500.
-a 16+GB microsd.
-Linux OS (Debian, Ubuntu, etc.)
-Linux 4 Tegra: Download the Ventana files under "Additional Information" and "Driver Packages"/"Codec Packages".
Ok, so here's how I've done it.
1) Make sure you have a multiboot loader and have flashed the appropriate bootloader image to the second boot partition. get the boot image from the 3rd guide under "precompiled kernel image" and flash that to the second boot partition. (be sure to check the dualboot guide above on flashing the image if you are using the bootloader that is in the guide.)
2) Have a microsd card partitioned with two partitions, one for normal data (can be any format) and a second one that is in ext4. you can do 3 partitions by adding a swap partition but the ext4 partition must be the second partition.
3) Install qemu on the host system.
Code:
For Ubuntu - sudo apt-get install qemu-user-static
4) Mount the microsd's ext4 partition.
Code:
sudo mount -t ext4 /dev/<microsd 2nd partition> /mnt/Linux
5) Run:
Code:
sudo qemu-debootstrap --arch armhf wheezy /mnt/Linux
6) Chroot into the installed environment.
Code:
chroot /mnt/Linux /bin/bash
7) Add sources to /mnt/Linux/etc/apt/sources.list. you can get debian sources from http://debgen.simplylinux.ch/. Be sure to choose "Testing (wheezy)" and all the sources check boxes along with where you live to find the nearest repository.
8) Install the wifi drivers pt1.
Code:
apt-get update ; apt-get install broadcom-sta-common broadcom-sta-source firmware-b43-installer firmware-b43legacy-installer b43-fwcutter
9) Install the wifi drivers p2. In the "{HOW TO} Native Debian on A500 and building your own rootfs" guide, there is a download from mediafire for the firmware files for the drivers. Extract that and put it into /lib/firmware. I dont know if the individual files in the brcm should be in the /lib/firmware or not so i just copied the folder into it and the files within it into /lib/firmware.
10) Install the GUI:
Code:
apt-get install <gui>
List of GUI's (that i know of):
Code:
KDE (takes a long time to install): kde-full
XFCE: xfce4
11) extract the ventana_Tegra-Linux-R16.1.0_armhf.tbz2 file and the ventana_Tegra-Linux-codecs-R16.1.0_armhf.tbz2. you should get a folder called "Linux_For_Tegra" and a file called "restricted_codecs.tbz2". go into the "Linux_For_Tegra/nv_tegra" folders and extract the nvidia_drivers.tbz2 file. from there you should get 3 folders: etc, lib, usr. copy those to "/mnt/Linux" (you are going to have to do this as root). back out of those folders and extract the restricted_codecs.tbz2. you should get a folder called "lib" copy that to "/mnt/Linux". after that, it's time to make a hard link so that the X11 can find the tegra driver:
Code:
ln /usr/lib/xorg/modules/drivers/tegra_drv.abi12.so /usr/lib/xorg/modules/drivers/tegra_drv.so
Note: without using an xorg.conf file, by default it will use fbdrv instead of the tegra driver.
12) set the root password:
Code:
passwd root
13) add a normal user:
Code:
adduser <username>
14) exit chroot by typing "exit" and unmount /mnt/Linux:
Code:
sudo umount /mnt/Linux
15) pop that sucker into the the tablet and boot into it by holding power and vol down to get into the boot menu. select "boot into second partiton".
If everything went ok, you should be presented with a gui, if not and you are at a command line, log into root and type "startx". if that doesnt work then something wrong must have happened.
Untested easy script:
Code:
#! /bin/sh
set -e
#if there is a tegra_install.deb file.
hasTegraDeb=0
tegraDeb=acer-iconia-tab-a500+tegra+brcm+wheezy_1.0-1_armhf.deb
#change these if you do not like default install of kde.
arch=armhf
build=wheezy
rootDir=/mnt/Linux
guiEnv=kde-full
newUser=User
#setup the basics of debian linux using armhf and wheezy build.
qemu-debootstrap --arch $arch $build $rootDir
#copy the tegra_install.deb file for the tegra specific drivers.
if ["$hasTegraDeb" = "1"] then
cp $tegraDeb $rootDir/$tegraDeb
fi
#setup sources.list for apt-get.
echo "deb http://ftp.us.debian.org/debian testing main contrib non-free" >> $rootDir/etc/apt/sources.list
echo "deb http://ftp.debian.org/debian/ wheezy-updates main contrib non-free" >> $rootDir/etc/apt/sources.list
echo "deb http://security.debian.org/ wheezy/updates main contrib non-free" >> $rootDir/etc/apt/sources.list
#create the chroot_install.sh script and set it up.
echo "#! /bin/sh" > $rootDir/chroot_install.sh
echo "set -e" >> $rootDir/chroot_install.sh
#update apt-get inside the chroot.
echo "apt-get update" >> $rootDir/chroot_install.sh
#install the wireless card drivers inside the chroot.
echo "apt-get install broadcom-sta-common broadcom-sta-source firmware-b43-installer firmware-b43legacy-installer b43-fwcutter" >> $rootDir/chroot_install.sh
#install the desktop in the chroot. (note: this will take a long time)
echo "apt-get install $guiEnv" >> $rootDir/chroot_install.sh
#install the tegra specific drivers inside the chroot
if ["$hasTegraDeb" = "1"] then
#install the tegra drivers.
echo "dpkg -i $tegraDeb" >> $rootDir/chroot_install.sh
#hard link the tegra_drv.abi12.so as tegra_drv.so in /usr/lib/xorg/modules/drivers/ to enable X11 to find the display driver.
echo "ln /usr/lib/xorg/modules/drivers/tegra_drv.abi12.so /usr/lib/xorg/modules/drivers/tegra_drv.so" >> $rootDir/chroot_install.sh
fi
#set the root password in the chroot.
echo "passwd root" >> $rootDir/chroot_install.sh
#add normal user in the chroot.
echo "adduser $newUser" >> $rootDir/chroot_install.sh
#execute the final stage of the install.
chroot $rootDir /chroot_install.sh
#cleanup
rm $rootDir/chroot_install.sh
if ["$hasTegraDeb" = "1"] then
rm $rootDir/$tegraDeb
fi
Script sets up everything along with installing kde window manager. Please note that the tegra_install.deb file does not exist, it is something that i am thinking of making in the future that has all the drivers and what not needed that is from the Linux 4 Tegra site. you are still going to have to manually install the tegra drivers in step 11.
Edit: Experimental copies of the deb files that has all the files needed from Linux 4 Tegra and the wifi drivers can be found at the bottom of the post.
xorg.conf to enable tegra driver (found in the Linux_for_Tegra/nv_tegra/config.tbz2/etc/X11 folder):
Code:
# This is the minimal configuration necessary to use the Tegra driver.
# Please refer to the xorg.conf man page for more configuration
# options provided by the X server, including display-related options
# provided by RandR 1.2 and higher.
# Disable extensions not useful on Tegra.
Section "Module"
Disable "dri"
Disable "dri2"
Disable "glx"
SubSection "extmod"
Option "omit xfree86-dga"
EndSubSection
EndSection
Section "Device"
Identifier "Tegra"
Driver "tegra"
# OverlayDepth is a 32-bit integer which is used to control overlay
# stacking order. The overlay with the lowest depth is in front of
# all others. This value has meaning only when multiple overlays are
# present on a display.
# Option "OverlayDepth" "255"
# ARGBHWCursor controls whether the X driver uses an overlay to
# display 32-bit "true-color" cursors, or whether such cursors are
# emulated in software. Valid values are "true" to enable hardware
# cursors, and "false" (default) to disable them.
# Option "ARGBHWCursor"
EndSection
At the moment, I have looked through the config.tbz2 file and may have to stick the stuff in there into the tablet's linux filesystem. will test this later.
NOTE:
I am not a linux developer, I have no idea how to create linux drivers. All I can do is mash things together and hope things work out.
In theory, this should work for all tegra2 and tegra3 (using cardhu drivers instead of ventana) devices with some minor differences.
Edit:
Apparently it is using kernel version 2.6.38. I'm going to see if I can update the kernel to 3.2.23-1 which is the latest version for armhf in the debian package list (http://packages.debian.org/wheezy/kernel/linux-headers-3.2.0-3-all-armhf).
Edit2:
Looks like updating the kernel from apt-get doesn't necessarily enable the kernel to load as it seems that the boot loader loads a prepackaged kernel that has been flashed into mmcblk0p7. Tried out kexec and the kernel doesn't support it so adding it to the /dev/inittab script is useless for loading up new kernels. I tried making the new kernel into a flashable image using mkbootimg that is found within the Linux 4 Tegra folder but it doesn't do anything and the image apparently isn't valid when i tried booting it from fastboot (black screen). along with that, apparently it changed my password on my encrypted /data partition's password (when i flashed it within linux using dd) so a word of caution with that. If anyone can help me out, i would like to try to create something similar to grub (or even port it) where it loads up new kernels from the microsd or a specified place based on a boot list.
deb Files (Install using "dpkg -i acer-iconia-tab-a500+tegra+brcm+wheezy_<version>_armhf.deb" within the linux environment of the tablet.):
1.0-1: acer-iconia-tab-a500+tegra+brcm+wheezy_1.0-1_armhf.deb
--takes care of steps 9 and 11 sans hard linking the X11 tegra drivers.
1.0-2: acer-iconia-tab-a500+tegra+brcm+wheezy_1.0-2_armhf.deb
--has pre-depends for the first part of the wifi driver installation so this should, in theory, install both part 1 and 2 of the wifi drivers.
--takes care of steps 8, 9, and 11 sans hard linking the X11 tegra drivers.
Update log:
10/17/2012: added updated version of the deb package.
10/16/2012: first version.
Ok, so since I cant post anything including into ongoing threads in the android development forum due to the 10 post required thing i'll just have to ask development questions here till i reach the 10 post requirement.
Can anyone point me into the direction for how the second boot image that you flash for the dual boot bootloader is created? Trying to figure out how to create an image so that it boots everything off the microsd card including the kernel. It seems that the kernel used in the guide is locked to 2.6.38 and if you update the kernel within the tablet's linux environment it doesnt load it up. so i need to figure out how to create a boot image so that it loads it up or create a boot image that has grub (or other bootloaders) installed on it to boot different linux images.
alatnet said:
Ok, so since I cant post anything including into ongoing threads in the android development forum due to the 10 post required thing i'll just have to ask development questions here till i reach the 10 post requirement.
Can anyone point me into the direction for how the second boot image that you flash for the dual boot bootloader is created? Trying to figure out how to create an image so that it boots everything off the microsd card including the kernel. It seems that the kernel used in the guide is locked to 2.6.38 and if you update the kernel within the tablet's linux environment it doesnt load it up. so i need to figure out how to create a boot image so that it loads it up or create a boot image that has grub (or other bootloaders) installed on it to boot different linux images.
Click to expand...
Click to collapse
You are on the right track with mkbootimg. I have not figured it all out myself yet.
You have to compile your arm linux kernel then make a bootable image with mkboot
I don't know if you have seen this or if. this will help---Nethams kernel compile commands are;
make ARCH=arm menuconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueable--j16
./mkbootimg --ramdisk dev/zero --kernel arch/arm/zimage -o ../recovery.img
I believe these are the commands he uses to compile his recovery image (boot.img)
It is my understanding that mkboot combines the kernel with a ram disk to make an image file that will boot the system
That image file can be placed in several places 1-primary boot position 2 recovery position 3 and if you have Skrilax dual boot secboot position
So it depends on what mkboot compiled as to what happens when that boot point is activated.
I am still trying to work out how Spdev and Netham combine or configure the kernel + initramfs+ ramdisk to create their bootable images.
I know these images boot and point to the file system which can be stored on internal or external sd card or even usb drive it all depends on how the boot image is configured.
Still learning myself
Here is a link I found explanes about Linux ram disk and initram
http://www.ibm.com/developerworks/linux/library/l-initrd/index.html
And more info here downloads a PDF presentation on how to.
http://www.google.com/url?sa=t&rct=...poCoAw&usg=AFQjCNHLTHE3DaroC71FAjOjQWU2A61qEQ
All about that mkbooting after you get your kernel
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
themechaniac said:
snip (freaking 10 post limit...)
Click to expand...
Click to collapse
Yea, i did find some stuff with mkbootimg including the last link that you posted.
The kernel was already compiled when i downloaded it using apt-get and it is placed in /boot folder.
I did make a boot.img from that kernel using mkbootimg and looking at "/proc/cmdline" at the arguments that were passed to the kernel in the other kernel image and it made it, flashed it to secboot and it didnt do anything except use the same kernal as before, though i did flash the image via dd in linux. Apparently this sorta screwed up my /data partition or something in where it wouldnt recognize my password for de-encryption to mount it. (fixing it by just erasing "/data" [bye bye data... TT.TT]) So i tried booting it using "fastboot boot <kernel>" and it didnt boot, only showing a black screen, but using the other boot.img it would boot linux up.
So I'm thinking of somehow creating a kernel image that can use kexec to make a grub like bootloader kernel that you flash onto the secboot partition that has something similer to grub.cfg in which you can easily select which kernel to load.
As for looking for a grub.cfg file, it would look in a few different places:
-in internal storage (probably recovery partition or the "/system" partition as the "/data" partition can potentially be encrypted and not mountable.)
-sd card (has to be in first partition and in fat32 format)
-usb drive (same as sd card)
from these places it will load each grub.cfg. that way it'll make the grub like bootloader kernel extendable in which kernel to load (i.e. have a linux system on usb that you want to boot from.)
I may be wrong but it is my understanding that the compiled kernel is in the boot image packed by mkbootimg.
The kernel is compiled to look for the compatible root file system in a particular place.
So when you change or use a boot image you change the kernel you are using.
So we have a system that;
Has a modified Linux kernel that selects the Android file system from internal memory installed in the first boot position.
We can put a Linux kernel compiled to find a compatible root file system say on external sd card in the second boot position.
We can replace the recovery image with a Linux kernel that finds a compatible root file system on the internal sd card.
That gives us a hardware selective three different systems (triple boot)
With fastboot on the PC we can quickly change any of the Three boot images, replace the recovery image or repair system.
I think all we need is a 3.2.23 kernel compiled thee separate ways and packaged with mkbootimg.
1st find root file system internel, 2nd find file system externel 3rd find file system usb
We already have two 2.6.38 kernels. One from Spdev (external root file system)and One from Netham {internal file system)
They are different kernels as Nethams has added modules.
I believe the were both compiled from the same Git.
I have tried switching the two boot images in second boot position with both root file systems installed and when you boot the second position
it switches to it's own file system.
I haven't tried swapping the root file positions yet.
themechaniac said:
I may be wrong but it is my understanding that the compiled kernel is in the boot image packed by mkbootimg.
The kernel is compiled to look for the compatible root file system in a particular place.
So when you change or use a boot image you change the kernel you are using.
So we have a system that;
Has a modified Linux kernel that selects the Android file system from internal memory installed in the first boot position.
We can put a Linux kernel compiled to find a compatible root file system say on external sd card in the second boot position.
We can replace the recovery image with a Linux kernel that finds a compatible root file system on the internal sd card.
That gives us a hardware selective three different systems (triple boot)
With fastboot on the PC we can quickly change any of the Three boot images, replace the recovery image or repair system.
I think all we need is a 3.2.23 kernel compiled thee separate ways and packaged with mkbootimg.
1st find root file system internel, 2nd find file system externel 3rd find file system usb
We already have two 2.6.38 kernels. One from Spdev (external root file system)and One from Netham {internal file system)
They are different kernels as Nethams has added modules.
I believe the were both compiled from the same Git.
I have tried switching the two boot images in second boot position with both root file systems installed and when you boot the second position
it switches to it's own file system.
I haven't tried swapping the root file positions yet.
Click to expand...
Click to collapse
Interesting. Though i think it needs to be a specific type of kernel (i.e bzImage or uImage instead of vmlinuz) to actually run. also, the precompiled kernel in the guide that i had used in the opening post had a command line where one option was "root=/dev/mmcblk1p2" which pretty much says for the kernel to look for the linux file system in the second partition on the sd card.
Yes with the way the system is formatted you cannot change out the kernel on the fly. It is basically hard coded in the boot image. Skrilax has given us a way to change boot positions so we don't have to sacrifice recovery position to boot second kernel. I have not seen any pre configured 3.2.23 kernels yet. The one that Netham posted boots from internal SD but causes problems for some people as not all a500 have their internal SD card formatted in the same memory block. It works great for me I prefer to have my root file system on a fast external SD so would like to modify or compile a kernel like Netham's. I find I run out of space when I have it internal. Netham's kernel has USB sound and seems to boot differt than Spdev's.
themechaniac said:
Yes with the way the system is formatted you cannot change out the kernel on the fly. It is basically hard coded in the boot image. Skrilax has given us a way to change boot positions so we don't have to sacrifice recovery position to boot second kernel. I have not seen any pre configured 3.2.23 kernels yet. The one that Netham posted boots from internal SD but causes problems for some people as not all a500 have their internal SD card formatted in the same memory block. It works great for me I prefer to have my root file system on a fast external SD so would like to modify or compile a kernel like Netham's. I find I run out of space when I have it internal. Netham's kernel has USB sound and seems to boot differt than Spdev's.
Click to expand...
Click to collapse
Right, but this is how the linux boot loader is going to go with, instead of loading the linux system (sans kernel and initrd) from the sd card, we create a boot.img that has a linux system built in that has a sole purpose of loading other linux systems using kexec.
Edit:
Here's how the path is going to go:
Startup-->Bootloader-->Linux Bootloader (loads linux on external drives)-->Linux (on external drives)
Well I am happy with Ubuntu on my external SD card, I even ran a kernel compile on it and it ran pretty fast. I am stuck on the mkbootimg part. It can't be done on the tablet, has to be a PC. I tried unpacking the Two ready made boot images to see how they are configured but they don't seem to have a ram disk. Still working on that. It is learning how the system is put together that is half the fun, Getting it to work the way you want is the goal. When it is all squared away it will be time to move on to the next puzzle. I have enough computers that I could just put a system on each one and be done with it. Where's the fun in that. Most of them are dual booted already.
themechaniac said:
Well I am happy with Ubuntu on my external SD card, I even ran a kernel compile on it and it ran pretty fast. I am stuck on the mkbootimg part. It can't be done on the tablet, has to be a PC. I tried unpacking the Two ready made boot images to see how they are configured but they don't seem to have a ram disk. Still working on that. It is learning how the system is put together that is half the fun, Getting it to work the way you want is the goal. When it is all squared away it will be time to move on to the next puzzle. I have enough computers that I could just put a system on each one and be done with it. Where's the fun in that. Most of them are dual booted already.
Click to expand...
Click to collapse
Well, even though mkbootimg is suppose to be run on linux, i don't think it was compiled for arm so you are going to have to use a pc for that program. as for the initrd, i did find a website that may help in creating an A.L.B.L. (Android Linux Boot Loader): http://www.thewireframecommunity.com/node/14
Essentially what is needed to create the A.L.B.L. is to create a kernel with kexec in it and an initrd that mounts the external drives along with an easy to use interface to be loaded before loading any kernels to allow for selecting kernels. with that said, how do you figure out how to use the volume buttons and the power button within linux using a c\c++ program?
BUMP!
any progress?
also
-Audio (Detects it in the kde info center. System Settings program only says that there's a dummy output. Playing any form of audio crashes the program.)
Click to expand...
Click to collapse
But
Code:
cat /any/file/for/ex/bin/bash > /dev/dsp
works properly
Unfortunetly no.
Been to busy with other stuff to work on this.
tegra driver
I have ubuntu 12.10 armf runing on my a500 thanks to the "Linux on A500: The Future" thread. I am using the ferrariforzaleo mod of rogro82's kernel.
The problem I had was getting the xorg tegra module to load. I fixed this by getting the "https://launchpad.net/ubuntu/quantal/armhf/nvidia-tegra/16.0-0ubuntu1"]https://launchpad.net/ubuntu/quantal/armhf/nvidia-tegra/16.0-0ubuntu1 and installing with
sudo dpkg -i
after I rebooted it started using the tegra video driver.
Cheers
HardlyAbelson said:
I have ubuntu 12.10 armf runing on my a500 thanks to the "Linux on A500: The Future" thread. I am using the ferrariforzaleo mod of rogro82's kernel.
The problem I had was getting the xorg tegra module to load. I fixed this by getting the "https://launchpad.net/ubuntu/quantal/armhf/nvidia-tegra/16.0-0ubuntu1"]https://launchpad.net/ubuntu/quantal/armhf/nvidia-tegra/16.0-0ubuntu1 and installing with
sudo dpkg -i
after I rebooted it started using the tegra video driver.
Cheers
Click to expand...
Click to collapse
can you explain me the steps you done ? I also want ubuntu 12.10 running but I can't install any desktop on it ( show error and other error )
ubuntu 12.10
Forzaferrarileo said:
can you explain me the steps you done ? I also want ubuntu 12.10 running but I can't install any desktop on it ( show error and other error )
Click to expand...
Click to collapse
Hi, I used the debootstrap and and qemu / chroot to setup my rootfs. i found post #61 in the "Linux on A500: future" very helpful.
Also, make sure you have a usb keyboard handy. After you run "apt-get install -d ubuntu-desktop" (assuming you have a pc running ubuntu to use) in a qemu chroot, you can move to the a500 and boot up and login as root and run "apt-get install ubuntu-destop". since the stuff is cached. I found this faster than installing the desktop while in the chroot. After that finishes, you should boot up with a desktop available. If something is wrong and you can't login, try doing "ctrl-alt-f1" to get to the getty command line login and look at the /var/log/ folder for clues in the logs.
How to compile the kernel?
I succesfully got debian running on my iconia a500 :laugh:
Building my own rootfs and getting the wifi to work were not that hard, but I still don't know how to compile the Linux kernel for the a500 from source.
I already found the git repository of rogru82 (https://github.com/rogro82/picasso-kernel) and I downloaded the source to my pc (running ubuntu 13.04). Can someone point me to a tutorial explaining how to compile this source?
Also, can someone explain what sort of partition table the internal memory uses? I am running the 3.0 kernel and I can see a block memory device in the /dev folder but there are no partitions. How can I mount the internal memory?
As anyone who has tinkered around with android and linux will know there are tons of different security mechanism in place or even general lacks of features that dissallow the ability to start linux on boot instead of android. One of the features that will make booting our own OS easier is the use of RAM-Disk.
First we must consider the way that Android boots when we turn on our devices currently, The system powers on and depending on button combination or system state the bootloader decides where to start booting. In the case of my Samsung SM-T520 this means that I have 2 partitions that I can access in order to interrupt the Android boot sequence and boot instead into an OS of my choosing. Those two partitions are Labelled as Boot and Recovery and reside at /dev/block/mmcblk0p9 and /dev/block/mmcblk0p10, but it is not as simple as simply mounting the partition and modifying the contents, we have to Modify the stock Kernel as well a little bit to be able to achieve better performance in the Linux side of things.
In the case of the SM-T520 I have compiled a preconfigured Kernel for this and will upload it below, But for those of you who do Not have the SM-T520 I will upload a sample Kernel config that you can base your own off of.
That settles the Kernel side of things but there is still 1 other part missing, If we just modify the Kernel then we are really not making any difference so we must edit...
The Initial RAMDISK
The Initramfs as many know it is glued to the back end of our kernel zImage that we get from compiling our own kernel, and includes a few small files to set up the initial environment for Android, or our Guest OS to finish booting from. This means that we have a pretty good base to start out with booting Linux. We simply have to grab this base and modify to our will.
So to start I took an image of /dev/block/mmcblk0p9 using dd from recovery like so ‘dd if=/dev/block/mmcblk0p9 of=sdcard/mmcblk0p9.img’ and copied the file onto my linux development machine. I then used umkbootimg passing the file to it as input in order to deconstruct that file into the zImage and the Ramdisk. i then copied the Ramdisk which will be in a file called initramfs.cpio.gz into a new folder on my computer and ran unpack_ramdisk on it to get to the nitty gritty inside which is what we need. and i promptly threw out the old initramfs.cpio.gz and kept only the ramdisk folder. This allowed me to modify the “scripts” inside of it so that it would boot Linux by mounting the linux install location as / then telling if to boot using the init function that linux already has. while I was testing i decided to leave the android install mounted essentially, what that means is that the android install hides away in the filesystem inside the linux install if we ever want to boot Android into a chroot Jail of its own.
That is possible because Android’s file system and the linux filesystem being used are the same structure, but at different locations /system being empty for the Android system to occupy. This is all fine, but where do we put linux? The short answer, Wherever the heck ya want to!
My answer was to put the linux install onto my MicroSD card at /dev/block/mmcblk1p1 so that i could write an addition to the logic inside the Ramdisk to start linux or android based on whether the SD card was inserted at boot.
More yet to follow
Interesting read. It will be great to see where this leads.
Very interesting. If this develops in would love to test.
Hei @DJHenjin1 , any update on this? I would love to see ubuntu running native on my SM-T520, especially now that it is sure we are not going to get any firmware update. Anyway, nice job! Thanks
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