Monday 12 May 2014
Thursday 8 May 2014
Tamilnadu +2 result 2014 (plus two result on 09th May 2014 at 10.00 am)
Click The following link for Tamilnadu 2014 +2 Result
+2 Result TamilNadu
+2 Result TamilNadu
+2 Result TamilNadu
+2 Result TamilNadu
+2 Result TamilNadu
Click here to check your TN +2 Results 2014 Official Website 1 : tnresults.nicin
Click here to Check your Tamilnadu 12th Results 2014 – Official Website 2 : dge1.tn.nic.in
Click here to Check your Tamilnadu +2 Results 2014 – Official Website 3 : dge2.tn.nic.in
Click here to Check your TN Higher Secondary Results 2014 – Official Website 4 : dge3.tn.nic.in
- See more at: http://academicindia.in/exam-results/tn-2-results-2014-tamilnadu-12th-results-marks-check-tnresults-nic/#sthash.yNYLOzin.dpuf
(Reference: http://academicindia.in/exam-results/tn-2-results-2014-tamilnadu-12th-results-marks-check-tnresults-nic/)
Click here to check your TN +2 Results 2014 Official Website 1 : tnresults.nicin
Click here to Check your Tamilnadu 12th Results 2014 – Official Website 2 : dge1.tn.nic.in
Click here to Check your Tamilnadu +2 Results 2014 – Official Website 3 : dge2.tn.nic.in
Click here to Check your TN Higher Secondary Results 2014 – Official Website 4 : dge3.tn.nic.in
- See more at: http://academicindia.in/exam-results/tn-2-results-2014-tamilnadu-12th-results-marks-check-tnresults-nic/#sthash.yNYLOzin.dpufClick here to check your TN +2 Results 2014 Official Website 1 : tnresults.nicin
Click here to Check your Tamilnadu 12th Results 2014 – Official Website 2 : dge1.tn.nic.in
Click here to Check your Tamilnadu +2 Results 2014 – Official Website 3 : dge2.tn.nic.in
Click here to Check your TN Higher Secondary Results 2014 – Official Website 4 : dge3.tn.nic.in
- See more at: http://academicindia.in/exam-results/tn-2-results-2014-tamilnadu-12th-results-marks-check-tnresults-nic/#sthash.yNYLOzin.dpufWednesday 7 May 2014
CP7212 Case Study - Operating Systems Design (Team Work)
DEVELOPMENT OF A REASONABLY SIZED DYNAMICALLY LOADABLE KERNEL MODULE
FOR LINUX KERNEL
AIM
To develop a
reasonably sized dynamically loadable kernel module for linux kernel.
Reasons for compiling
a custom kernel
·
The kernel need to be compiled in a special way
that the official kernel is not compiled in (for example, with some
experimental feature enabled).
·
Attempt
and debug a problem in the stock Ubuntu kernel for which it have to be filed or
will file a bug report.
·
Hardware stock of Ubuntu kernel does not support.
Reasons for NOT
compiling a custom kernel
·
There is a need to compile a special driver. For
this, it is necessary to install the linux-headers packages.
To install a new kernel without compilation,
we can use Synaptic, search for linux-
image and select the kernel
version you want to install.
An easier way is to click on
System > Administration > Update Manager, then click on the Check button,
and finally click on Apply all updates including the kernel.
Tools needed
To
start, there is a need to install a few
packages. The exact commands to install those packages depend on which release
you are using:
·
Hardy
(8.04):
sudo
apt-get install linux-kernel-devel fakeroot kernel-wedge build-essential
Note:
The package makedumpfile is not available in Hardy.
·
Lucid
(10.04):
sudo apt-get
install fakeroot build-essential crash kexec-tools makedumpfile kernel- wedge sudo apt-get build-dep linux sudo
apt-get install git-core libncurses5 libncurses5-dev libelf-dev asciidoc
binutils-dev
Get the kernel source
There are a
few ways to obtain the Ubuntu kernel source:
A) Use git
·
Use git (detailed instructions on it can be
found in the Kernel Git Guide) - This is for users who always want to stay in
sync with the latest Ubuntu kernel source.
The git
repository does not include necessary control files, so you must build them by:
fakeroot debian/rules clean
B) Download the
source archive
·
Download the source archive - This is for users
who want to rebuild the standard Ubuntu packages with additional patches. Note
that this will almost always be out of date compared to the latest development
source, so you should use git (option A) if you need the latest patches.
To
install the build dependencies and extract the source (to the current
directory):
Ubuntu Hardy (8.04)
sudo
apt-get build-dep --no-install-recommends --only-source linux
apt-get
source --only-source linux
·
Ubuntu modules source may also be needed if you
plan to enable PAE and 64 GiB support in the kernel for 32-bit Hardy (8.04). The
Ubuntu supplied modules may not be compatible with a PAE enabled kernel.
sudo
apt-get build-dep --no-install-recommends linux-ubuntu-modules-$(uname -r)
apt-get
source linux-ubuntu-modules-$(uname -r)
·
The source will be downloaded to a subdirectory
inside the current directory.
Ubuntu Karmic Koala (9.10) and newer
releases
sudo
apt-get build-dep --no-install-recommends linux-image-$(uname -r)
apt-get
source linux-image-$(uname -r)
·
The source will be downloaded to the current
directory (for Lucid, at least) as a trio of files (.orig.tar.gz, .diff.gz, and
.dsc) and a sub-directory. For instance, if uname -r returns 2.6.32-25-generic,
you'll obtain linux_2.6.32.orig.tar.gz, linux_2.6.32-25.44.diff.gz,
linux_2.6.32-25.44.dsc and the sub-directory linux-2.6.32.
C) Download the
source package
·
Download the source package (detailed
instructions are further down this page under Alternate Build Method: The
Old-Fashioned Debian Way) - This is for users who simply want to modify, or
play around with, the Ubuntu-patched kernel source. Again, this will not be the
most up-to- date (use option A/git if you need the latest source). Please be
aware this is NOT the same as option B.
Modify the source for
your needs
The stock Ubuntu configs
are located in debian/config/ARCH/ where ARCH is the architecture you are
building for (Starting with Jaunty this debian.master/config/ARCH/). In this
directory there are several files. The config file is the base for all targets
in that architecture. Then there are several config.FLAVOUR files that contain
options specific to that target. For example, here are the files for 2.6.20,
i386:
If there is no config files under
debian/config, find them in your /boot directory (for instance,
/boot/config-2.6.22-14-generic) otherwise you should check to see if an
alternate location has been specified within debian/debian.env of your kernel
source directory.
If
there is a need to change a config
option, simply modify the file that contains the option. If you modify just the
config file, it will affect all targets for this architecture. If you modify
one of the target files, it only affects that target.
After
applying a patch, or adjusting the configs, it is always best to regenerate the
config files to ensure they are consistent. There is a helper command for this.
To regenerate all architectures run:
debian/rules
updateconfigs
To update one architecture, run:
debian/scripts/misc/oldconfig
ARCH
Note: If there is no debian/ directory
after using apt-get source, use dpkg-source -x *dsc to extract the sources
properly.
For
these two commands to work, you need to give the scripts in the
debian/scripts/misc and debian/scripts directories execute permission with the
following command:
chmod
-R u+x debian/scripts/*
Build the kernel
(when source is from git repository, or from apt-get source):
To
build the kernel(s) is very simple. Depending on your needs, you may want to
build all the kernel targets, or just one specific to your system. However, you
also want to make sure that you do not clash with the stock kernels.
Note:
Though these outside instructions include making a separate and unique branch
of the kernel, unlike here, they include thorough explanations of all necessary
steps from start to finish.
·
Oneiric (11.10) Kernel 3.2 :
http://blog.avirtualhome.com/2012/01/13/compile-linux-kernel-3-2-for-ubuntu-11-10/
·
Oneiric (11.10) :
http://blog.avirtualhome.com/2011/10/28/how-to-compile-a-new-ubuntu-11-10-oneiric-kernel/
·
Maverick on Lucid (10.04):
http://blog.avirtualhome.com/2010/07/14/how-to-compile-a-
ubuntu-2-6-35-kernel-for-lucid/
·
Lucid (10.04):
http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-
kernel/
These instructions are specific to the
git-tree and for the source downloaded via apt-get source, not when downloading the linux-source package from kernel.org
Use
this command to build all targets for the architecture you are building on:
fakeroot debian/rules clean
AUTOBUILD=1 fakeroot debian/rules
binary-debs
debian/rules clean creates debian/control,
debian/changelog, and so on from
debian.<branchname>/*
(e.g. debian.master).
It is necessary in git trees following git
commit 3ebd3729ce35b784056239131408b9a72b0288ef
"UBUNTU: [Config] Abstract the debian
directory".
The
AUTOBUILD environment variable triggers special features in the kernel build.
First, it skips normal ABI checks (ABI is the binary compatibility). It can do
this because it also creates a unique ABI ID. If you used a git repo, this
unique ID is generated from the git HEAD SHA. If not, it is generated from the
uuidgen program (which means every time you execute the debian/rules build, the
UUID will be different!). Your packages will be named using this ID. (Note that
in Intrepid and newer, you will need skipabi=true to skip ABI checks.)
To
build a specific target, use this command:
fakeroot debian/rules clean
AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules
binary-FLAVOUR
Where FLAVOUR is one of the main flavours of
the kernel (e.g. generic)
To build one of the custom flavours (found
in debian/binary-custom.d/), use:
fakeroot debian/rules clean
AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules
custom-binary-FLAVOUR
·
If there are more than one processor or more than one core,
it can speed things up by
running
concurrent compile commands. Prepend CONCURRENCY_LEVEL=2 for two
processors or
two cores; replace '2' with whatever number suits your hardware setup (for Gutsy and later, you can alternatively use
DEB_BUILD_OPTIONS=parallel=2). fakeroot debian/rules clean
DEB_BUILD_OPTIONS=parallel=2
AUTOBUILD=1 NOEXTRAS=1 fakeroot
debian/rules binary-generic
·
If there are ABI errors, you can avoid the ABI
check with skipabi=true. For example,
fakeroot
debian/rules clean
DEB_BUILD_OPTIONS=parallel=2
AUTOBUILD=1 NOEXTRAS=1
skipabi=true
fakeroot
debian/rules binary-generic
·
To trigger a rebuild, remove the appropriate
stamp file from debian/stamps (e.g. stamp-build-server for the server flavour,
etc.). The debs are placed in your kernel directory's parent directory.
·
If needed, the Ubuntu modules source for Hardy
(8.04) can be built in a similar way.
cd
linux-ubuntu-modules-2.6.24-2.6.24
AUTOBUILD=1
fakeroot debian/rules binary-debs
Alternatively,
if you need to specify a different kernel than the running one, use cd linux- ubuntu-modules-2.6.24-2.6.24
AUTOBUILD=1
fakeroot debian/rules binary-debs KDIR=/path/to/kerneldir
·
If you get an error, try running this in the
kerneldir: (example for the generic flavour) cat debian/config/i386/config
debian/config/i386/config.generic > .config make prepare scripts.
Alternate Build
Method: The Old-Fashioned Debian Way :
The
new Ubuntu build system is great for developers, for people who need the
absolute latest bleeding-edge kernel, and people who need to build a diverse
set of kernels (several "flavours"). However it can be a little
complex for ordinary users. If you don't need the latest development sources,
there is a simpler way to compile your kernel from the linux-source package. As
suggested above, all you need for this is:
sudo
apt-get install linux-source device-tree-compiler#
device-tree-compiler is only needed
if you are targeting the PowerPC architecture
mkdir
~/src
cd
~/src
tar
xjvf /usr/src/linux-source-<version-number-here>.tar.bz2
cd
linux-source-<version-number-here
Now
you are in the top directory of a kernel source tree. Before building the
kernel, you must configure it. If you wish to re-use the configuration of your
currently-running kernel, start with
cp
-vi /boot/config-ùname -r` .config
Before
you run make menuconfig or make xconfig (which is what the next step tells you
to do), make sure you have the necessary packages:
sudo
apt-get install qt3-dev-tools libqt3-mt-dev # if you plan to use 'make xconfig'
sudo
apt-get install libncurses5 libncurses5-dev # if you plan to use 'make
menuconfig'
If
you would like to see what is different between your original kernel config and
the new one (and decide whether you want any of the new features), you can run:
make oldconfig
Since the 2.6.32 kernel, a new feature
allows you to update the configuration to only compile modules that are
actually used in your system:
make localmodconfig
Then,
regardless of whether you're re-using an existing configuration or starting
from scratch:
make
menuconfig # or "make xconfig"
If
you re-used the existing configuration, note that Ubuntu kernels build with
debugging information on, which makes the resulting kernel modules (*.ko files)
much larger than they would otherwise be.
To
turn this off, go into the config's "Kernel hacking"<!-- ; then,
under "Kernel debugging", --> and turn OFF "Compile the
kernel with debug info".
Now
you can compile the kernel and create the packages:
make
clean # only needed if you want to do a "clean" build
make
deb-pkg
You
can enable parallel make use make -j). Try 1+ number of processor cores, e.g. 3 if you have a dual core
processor:
make
-j3 deb-pkg
The
*.deb packages will be created in the parent directory of your Linux source
directory (in this example, they would be placed in ~/src because our Linux
source directory is ~/src/linux-source-<version-number-here>).
Install the new kernel
If
you want to see the Ubuntu splash screen (or use text mode) before you get to X
instead of just a black screen, you'll want to make sure the framebuffer driver
loads:
echo
vesafb | sudo tee -a /etc/initramfs-tools/modules
echo
fbcon | sudo tee -a /etc/initramfs-tools/modules
Now
that you've told initramfs-tools which modules it should include, and once the
build is complete, you can install the generated debs using dpkg:
sudo
dpkg -i linux-image-2.6.20-16-2be-k7_2.6.20-16_i386.deb
sudo
dpkg -i linux-headers-2.6.20-16-2be-k7_2.6.20-16_i386.deb
Similarly,
if you have built the Ubuntu module for Hardy (8.04) earlier, install them as
follows:
sudo
dpkg -i linux-ubuntu-modules-2.6.24-16-generic_2.6.24-16.23_i386.deb
sudo
dpkg -i linux-headers-lum-2.6.24-16-generic_2.6.24-16.23_i386.deb
If
you use modules from linux-restricted-modules, you will need to recompile this
against your new linux-headers package.
Note:
In response to the various comments in the remainder of this section: On Ubuntu
Precise (12.04) it appears that postinst DOES take care of the initramfs stuff.
After installing the package my new kernel booted just fine without following
any of the methods below. Someone please correct me if I'm mistaken.
Since
Ubuntu Lucid (10.04) the image postinst no longer runs the initramfs creation
commands. Instead, there are example scripts provided that will perform the
task. These scripts will work for official kernel images as well. For example:
First copy the default overlay
directory to your home directory:
$ cp -r /usr/share/kernel-package $HOME
Then
install the source of the kernel you are using currently, using the exact
package name, e.g.
$ cd
$
apt-get source linux-image-2.6.32-24-generic
which
will unpack the sources to $HOME/linux-2.6.32. Now copy the control scripts
into your newoverlay:
$cplinux-2.6.32/debian/control-scripts/{postinst,postrm,preinst,prerm}kernel package/pkg/image/
$ cp
linux-2.6.32/debian/control-scripts/headers-postinst
kernel-package/pkg/headers/
And
now you can execute make-kpkg with the additional command line option
--overlay-
dir=$HOME/kernel-package.
Rebuilding ''linux-restricted-modules''
The
linux-restricted-modules (l-r-m) package contains a number of non-DFSG-free
drivers (as well as some firmware and the ipw3945 wireless networking daemon)
which, in a perfect world, wouldn't have to be packaged separately, but which
unfortunately are not available under a GPL-compatible license. If you use any
of the hardware supported by the l-r-m package, you will likely find that your
system does not work as well after switching to a custom kernel. In this case
you should try to compile the l-r-m package.
Note:
you will need around 8 hours of compilation time and around 10 Gb of hard drive
space to compile all kernel flavours and restricted modules.
Further
note: There are no l-r-m or linux-restricted-modules packages in Lucid.
Speeding Up the Build
If
you have AMD64 machines available on your local net, they can still participate
in building 32-bit code; distcc seems to handle that automatically. However,
with distcc taking over all compiles by default, you will need to set HOSTCC so
that when kernel builds want to use the compiler on the host itself, they don't
end up distributing jobs to the 64-bit server. If you fail to do that, you'll
get link-compatibility failures between 64-bit and 32-bit code. My make-kpkg
command, with /usr/lib/ccache at the head of my $PATH, looks like:
MAKEFLAGS="HOSTCC=/usr/bin/gcc
CCACHE_PREFIX=distcc"
make-kpkg -- rootcmd fakeroot --initrd
--append-to-version=-suspend2 kernel-image kernel-headers kernel-source
Upgrading The Linux Kernel.
To
upgrade your kernel, run the commands below to update all packages and existing
kernels.
sudo
apt-get update && sudo apt-get dist-upgrade && sudo apt-get
autoremove
After
updating your machine, restart your machine. It’s always good to restart after
upgrading your system packages and kernel. Doing so allows for newer kernels to
be applied.
Next,
run the commands below to download Linux Kernel 3.12.7.
For 32-bit Machines,
run the commands below
For 64-bit System,
run the commands below
After downloading the version for
your system, run the commands below to install it.
sudo
dpkg -i *.deb
LOADABLE KERNEL MODULE
How to Create LKMs
Lets create
a basic loadable kernel module.
·
The names ‘init_module’ and ‘cleanup_module’ are
standard names for an LKM.
·
If you see closely then you will find that we
have used ‘printk’ instead of ‘printf’. This is because it is not a normal C
programming, its a kernel level programming which is a bit
different from
normal user level programming.
·
The headers module.h and kernel.h has to be
included to get the code compiled.
How to Compile LKMs
To compile the above LKM, I used the following Makefile :
obj-m
+= lkm.o
all:
sudo
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
sudo
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
After
the above successful compilation you will find a .ko file in the same directory
where the compilation took place.
This . ko file is the module that will be loaded in the kernel. modinfo
utility can be used to fetch the information about this module :
How LKM is Loaded
After
a successful compilation and creation of the module, now is the time to insert
it in the kernel so that it gets loaded on run time. The insertion of the
module can be achieved using the following two utilities :
·
modprobe
·
insmod
The difference between the two lies in the fact that ‘modprobe’ take
care of the fact that if the module in dependent on some other module then that
module is loaded first and then the main module is loaded. While the ‘insmod’
utility just inserts the module (whose name is specified) into the kernel. So
‘modprobe’ is a better utility but since our module is not dependent on any
other module so we will use ‘insmod’ only.
So, to insert the module, the
following command is used :
$
sudo insmod ./lkm.ko
if this command does not give any
error then that means the LKM is loaded successfully in the kernel. To unload
the LKM, the following command is used :
$
sudo rmmod lkm.ko
To
check that the module was loaded and unloaded correctly we can use the dmesg
utility which gives the last set of logs as logged by the kernel. You’ll see
the following two lines among all the other logs :
....
....
[
4048.333756] Welcome.....
[
4084.205143] Bye....
If
you go back to the code and see then you will realize that these are the logs
from the two functions in the code. So we see that one function was called when
the ‘insmod’ was called and the other function was called when the ‘rmmod’ was
called.
This was just a dummy LKM. In
this way many working LKM (that carry out meaningfutasks) work inside Linux
kernel.
Eg: hello.c:
The program requires you to
include -D options on your compile
command to work, because it
does not define some macros in
the source code, where the definitions belong.
Here is an improved world's
simplest LKM, hello.c
.
Compile this with the simple command:
$ gcc
-c -Wall -nostdinc -I /usr/src/linux/include hello.c
References:
2.
http://www.liberiangeek.net/2014/01/daily-ubuntu-tips-linux-kernel-3-12-7-released-
heres-how-to-upgrade-in-ubuntu/
7.
http://xda-university.com/as-a-developer/getting-started-building-a-kernel-from-
source
RESULT:
Thus the reasonably sized
dynamically loadable kernel module was developed successfully.
EDUCATIONAL OPERATING SYSTEMS MINIX
AIM
To study
educational operating systems such as minix and weenix and to develop a
reasonably sized modules.
Installing Minix3 in Virtualbox
1.
Start by downloading the installation disk from
a. http://www.minix3.org/iso/minix_R3.2.0-116fcea.iso.bz2
2.
Extract it to a location easy to find.
3.
Now open virtualbox and click the “New” button
in the main window.
4.
Click Next and choose a Name for the virtual
machine, I chose “Minix”. Under OS Type,
choose “Other”
And “Other/Unknown” and click Next.
5.
When setting memory for the virtual machine,
256MB should be enough.
6.
Create a new virtual disk by choosing VDI
(VirtualBox Disk Image) and click Next.
Because
we’ll only be using 2 GB I chose a “Fixed Size” disk image.
7.
Finish the disk creation setup and open up
virtualbox’s main window. Right click and
choose
settings on the new virtual machine we just created.
8.
Go to
Network in the settings window and click advanced. Choose PCNET-PCI II
(am79c970a) as network adapter.
9.
Go to storage and select the empty cdrom. Click
on the little cd icon on the top right, in the dropdown list, choose: “Choose a
virtual CD/DVD disk file..”. Browse your way to where you extracted the Minix iso file, select it,
and click “Open”.
10.
Click “OK” to close the settings window. Now you
are ready to power on the virtual
machine.
11.
Select the virtual machine and click “Start”
12.
A new windows appears, in the minix bootloader,
choose 1.
13.
The system boots up and prompts you with a log
in screen, type “root” to log in.
14.
Then type in “setup” to start the install
scripts.
15.
Type “Enter” to continue.
16.
If you have and us keyboard or know the us
mapping on your keyboard, just type “enter”
to continue. After that just follow the partition setup prompt.
17.
The next step is to partition the disk. Just
press “Enter” for setting up the partition automatically and follow the
instructions given on screen.
18.
After Minix3 setup script has finished copying
files to the new drive you get a choice of
which
ethernet chip. Just choose alternative 8. “AMD LANCE” by typing “Enter”.
19.
On the next prompt MINIX how it should configure
the network, just use the default choice (1. Automatically using DHCP) by
typing “Enter”. The setup is now done and you
get
back to the root shell. Type in “shutdown” to reboot the system.
20.After the
system shuts down, right click on the minix virtual machine and choose settings in the virtualbox main window.
Go to storage and select the cdrom again. Click at the cd icon to get the
dropdown menu up in the top right hand corner and choose “Remove disk from
virtual drive”. Click “OK” and start the virtual machine.
20.
When you
get the logon prompt, just type in “root” and press “enter”.
21.
MINIX3 is installed.
Installing MINIX in PCs
1. Getting MINIX
Download the
CD-ROM installer image from the http://www.minix3.org/download.
2. Preparation & Booting
Creating a bootable CD-ROM
a. Decompress
the downloaded file. You will get a CD-ROM image file with extension .iso.
b. The
.iso file is a bit-for-bit CD-ROM
image. Burn it to a CD-ROM disk to create a bootable MINIX
c. CD-ROM.
Please consult your CD burning program's documentation to learn how to burn ISO
d. images
to CD-ROM media.
e. If
you are running Windows XP and do not have a CD-ROM burning program, take a
look at http://alexfeinman.brinkster.net/isorecorder.htm
for a free one and use it to create a CD image.
Booting
from CD-ROM
a. Insert
the CD-ROM into your CD-ROM drive and boot the computer from it. If the
b. computer
boots from the hard disk instead of the CD-ROM, boot again and enter the BIOS
c. setup
program to change the order of boot devices, putting the CD-ROM before the hard
disk.
Partitioning your hard disk
Boot the
computer from your CD-ROM if you like and MINIX will start, but to do
anything useful, you have to create a
partition for it on your hard disk. But before partitioning, be sure to back
up your data.
Setting up a virtual machine
If you want to
run MINIX on a virtual machine instead of natively, see the installation
page for your VM of choice before
reading this page:
1. VMware
2. Qemu
(and KVM)
3. Bochs
4. Parallels
5. VirtualBox
6. Microsoft
VirtualPC 2007
3. Installation
Running the Setup script
a. When
the login prompt appears, login as
root. Press Enter when prompted for a
password.
b. To
start the installation of MINIX on the hard disk, type
Setup
a. After
this and all other commands, be sure to type ENTER (RETURN). When the
installation script ends a screen with a colon, hit ENTER to continue.
b. If
the screen suddenly goes blank, press CTRL-F3 to select software scrolling
(should only be needed on very old computers).
Select keyboard type
The us-swap keyboard interchanges the CAPS
LOCK and CTRL keys, as is conventional
on UNIX systems.
Create or select a partition for
MINIX
a. Start
MINIX disk partitioning.
b. Press
ENTER for the default action, which is an automated step-by-step guide to formatting
a disk partition for MINIX.
Select a disk
c. An
IDE controller may have up to four disks.
d. The
setup script will now look for each one. Just ignore any error messages.
e. When
the drives are listed, select one. and confirm your choice.
Select
a disk region
Now choose a region to install MINIX into.
You have three choices:
a. Select
a free region
b. Select
a partition to overwrite
c. Delete
a partition to free up space and merge with adjacent free space
d. For
choices (1) and (2), type the region number.
For (3) type:
e. Delete
then give the region number when asked. This region will be overwritten
and its previous contents lost forever.
Confirm your choices
a. Press
continues. If you do, the data in the selected region will be lost forever.
b. If
you are sure, type: yes and then
ENTER.
c. To
exit the setup script without changing the partition table, hit CTRL-C.
Select the size of /home
The
selected partition will be divided into three sub partitions: root,
/usr, and /home. The latter is for
your own personal files. Specify how much of the partition should be set aside
for your files. You will be asked to confirm your choice.
Select a block size
Disk block sizes
of 1-KB, 2-KB, 4-KB, and 8-KB are supported, but to use a size larger
than 4-KB you have to change a
constant and recompile the system. Use the default (4 KB) here.
Wait for files to be copied
Files will be
automatically copied from the CD-ROM to the hard disk. Every file will be
announced as it is copied.
Select your Ethernet chip
Select
Ethernet drivers to install. Network settings can be changed after
installation.
Restart
When the copying
is complete, MINIX is installed. Shut the
system down by typing:
shutdown
MINIX 3 Kernel API
1. Organization of Kernel Calls
A kernel call
means that a request is sent to a kernel where it is handled by one of the
kernel tasks. The details of assembling a request message, sending it to the
kernel and awaiting the response are conveniently hidden in a system library.
The header file of this library is src/include/minix/syslib.h
and its implementation is found in src/lib/syslib.
The actual
implementation of the kernel calls is defined in the SYSTEM kernel task. Suppose
that a program makes a sys_call()
system call. By convention, this call is transformed into a request message
with type SYS_CALL that is sent to
the kernel task SYSTEM. The SYSTEM task
handles the request in a function named do_call()
and returns the result.
The mapping of
kernel call numbers and handler functions is done during the SYSTEM
task's initialization response. src/kernel/system.c. The prototypes of
the handler functions are declared in src/kernel/system.h.
Their implementation is contained in separate files in the directory src/kernel/system/. These files are
compiled into the library /src/kernel/system/system.a
that is linked to the kernel.
The
kernel call numbers and their request and response parameters are defined
in src/include/minix/com.h.
Kernel calls all start with SYS_ and
all parameters that belong to the same kernel call share a common prefix.
2. Overview of kernel calls in MINIX 3
A
concise overview of the kernel calls in MINIX 3 is given in Table 1.
Kernel Call
|
Purpose
|
PROCESS MANAGEMENT
|
|
SYS_FORK
|
Fork a process; copy parent
process
|
SYS_EXEC
|
Execute a process; initialize
registers
|
SYS_EXIT
|
Exit a user process; clear
process slot
|
SYS_NICE
|
Change priority of a user
process
|
SYS_PRIVCTL
|
Change system process
privileges
|
SYS_TRACE
|
Trace or control process
execution
|
SYS_SETGRANT
|
Tell kernel about grant table
|
SYS_RUNCTL
|
Set/clear stop flag of a
process
|
SIGNAL HANDLING
|
|
SYS_KILL
|
Send a signal to a process
|
SYS_ENDKSIG
|
Tell kernel signal has been
processed
|
SYS_SIGSEND
|
Start POSIX-style signal
handler
|
SYS_SIGRETURN
|
Return POSIX-style signal
|
MEMORY MANAGEMENT
|
|
SYS_NEWMAP
|
Install new or updated memory map
|
SYS_MEMSET
|
Fill a physical memory area with a constant
pattern byte
|
SYS_VMCTL
|
(to be documented)
|
COPYING DATA
|
|
SYS_UMAP
|
Map virtual to physical address
|
SYS_VUMAP
|
Batch map virtual to physical addresses
|
SYS_VIRCOPY
|
Copy data using virtual addressing
|
SYS_PHYSCOPY
|
Copy data using physical
addressing
|
SYS_SAFECOPYFROM
|
Copy from a grant into own address space
|
SYS_SAFECOPYTO
|
Copy from own address space into a grant
|
SYS_VSAFECOPY
|
Handle vector with safe copy
requests
|
SYS_SAFEMEMSET
|
Fill a grant with a constant
pattern byte
|
DEVICE I/O
|
|
SYS_DEVIO
|
Read or write a single device
register
|
SYS_SDEVIO
|
Input or output an entire data
buffer
|
SYS_VDEVIO
|
Process vector with multiple
requests
|
SYS_IRQCTL
|
Set or reset an interrupt
policy
|
SYS_IOPENABLE
|
Give process I/O privilege
|
SYS_READBIOS
|
Copy from the BIOS area
|
SYSTEM CONTROL
|
|
SYS_ABORT
|
Abort MINIX: shutdown the
system
|
SYS_GETINFO
|
Get a copy system info or kernel data
|
SYS_SYSCTL
|
(to be documented)
|
CLOCK FUNCTIONALITY
|
|
SYS_SETALARM
|
Set or reset a synchronous
alarm timer
|
SYS_TIMES
|
Get process times, boot time
and uptime
|
SYS_STIME
|
Set boot time
|
SYS_VTIMER
|
Set or retrieve a process
virtual timer
|
PROFILING
|
|
SYS_SPROF
|
(to be documented)
|
SYS_CPROF
|
(to be documented)
|
SYS_PROFBUF
|
(to be documented)
|
Common Tests
Test Suite
a. Running
the test suite could take several hours.
b. At
the time of writing, not all tests pass on arm.
c. There
is a suite of tests which can be run to ensure that many of the software
features are working properly.
cd
/usr/tests/minix-posix
sh run
Real time clock, readclock, and rebooting
a. The
boards each have a hardware real time clock, similar to the CMOS clock on i386.
It
b. should
keep track of time while the board is running and between reboots.
c. Run
the date command to see the current date/time. Set the system date/time and run
date
d. again
to see the new, correct, date/time.
date
date
201309161200
date
e. Write
the date/time to the hardware real time clock.
readclock
-w
f. Run
readclock to read the hardware clock. Run date again to see that the correct
date/time have been read from the
hardware clock.
date
date
201301010000
date
readclock
date
g. Test
the reboot feature and ensure that the real time clock keeps working between
reboots.
reboot
h. Log
in and run the date command. It should have the right date/time.
date
References:
1.
http://www.netcrawlr.net/2012/09/installing-minix-3-in-virtualbox/
2.
http://wiki.minix3.org/DevelopersGuide/TestingMinixARM
RESULT
Thus the educational operating systems
such as minix and weenix has been studied and modules for them have been developed
successfully.
ANDROID OPEN SOURCE OPERATING SYSTEM FOR MOBILE DEVICES
AIM
To study and
develop modules for mobile devices using
android open source operating systems .
VirtualBox Installation
·
Download the Android 4.3 x86 iso from its Google
code page. As of this post, the build is
·
“Android-x86-4.3-20130725.iso”.
·
Install VirtualBox on Linux 64 bit Platform.
·
To install VirtualBox, do
sudo apt-get update
sudo apt-get install VirtualBox-4. 3
sudo apt-key add oracle_vbox.asc
Or
wget -q
http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc -O- | sudo
apt-key add –
Android Installation
In VirtualBox, create a new machine for Android.
1. Click
the “New” button. Enter a name for this virtual machine
2. Select
“Linux” for the Type and “Linux 2.6″ for the version.
3. Allocate a minimum of 2GB RAM for this VM.
4. Create
hard Disk space of new 16GB VDI image that dynamically expands.
5. Select
Networking with following requirements
·
Type: NAT
·
Adaptor: "Intel Pro/1000 MT Desktop
(82540EM)"
6. Select
Audio as Intel AC'97.
7. Choose
Storage Layout as
·
IDE Controller:
i.
CD Device
·
SATA Controller:
i.
Hard Disk
8. Under
the Storage section, select the CD/DVD drive slot and add the Android 4.3 iso
to the list.
Installing Android 4.3
Make sure
the VM boots from the ISO image.
•
On the boot screen, select "Installation - Install Android-x86 to
harddisk"
·
Choose "Create/Modify Partitions".
This takes you into cfdisk.
a. Choose
"[New]"
b. Choose "[Primary]"
c. Press
enter to accept the default partition size.
d. Choose
"[Bootable]"
e. Choose
"[Write]"
f. Type
"yes" to confirm writing.
g. Choose
"[Quit]"
Choose
to install on the sda1 device (Linux VBOX HARDDISK)
Choose
to format the drive "ext3"
·
Pick "Yes" to confirm formatting.
·
Pick "Yes" when it asks to install the
GRUB bootloader.
·
Pick "Yes" when it asks to mount
/system as read-write (this will be important later to Install the Google
apps).
·
Create a fake SD card when it prompts. I made
mine 2047MB (the maximum allowed).
·
Choose "<Reboot>"
Running Android 4.3 in VirtualBox
Reboot the
virtual machine. On the first bootup, it will take some time for the OS to load
and initialize. Subsequent boot up will be faster. Once you are in the Welcome
screen, follow the Setup wizard to setup Android 4.3.
At this point, you might want to disable the mouse
integration so that the mouse cursor will appear in the screen. This will make
the navigation process much easier.
While setting it up, it might not be able to detect any
Wi-Fi network. You can safely skip the Wi-Fi setup as it won’t affect your
Internet connection. It is also not necessary to sign in to your Google
account. It will take you to the Home screen once the setup is completed.
Modify Kernel Modules
Requirements to
modify android kernel modules
1. A
Linux installation (a PC on which a linux distro is installed) or Linux box
(May be a live cd or vmware like box). Any linux distro will do, but I assume
an Ubuntu installation to simplify the explanation.
2. A
toolchain-Either the Android NDK, or your own toolchain
3. Android
kernel source code for your device. This tutorial describes instruction for
both the Htc Desire and Samsung Galaxy Note N7100. With minor differences, the
method is practically the same for any Android device.
4. Familiarity
with the linux shell and basic linux commands.
Getting the source code
1. At
this point, you need to download the source code for your kernel. There are
generally, two ways to get kernel source code:
a. From
a compressed archive uploaded by the manufacturer of the device.
b. From
a git repository of another developer.
Choose the first method.
2. The
HTC Desire source is available from two kinds of resources-you can either get
it from htcdevs.com (official HTC Dev site), or from source code uploaded from
someone else. Assume we’re working on the official HTC GB source code. So
download bravo_2.6.35_gb-mr.tar.gz from htcdevs.com.
3. In
case, you’re working on a Samsung kernel, you can get your source code from
http://opensource.samsung.com/.
a. 4.
In many cases, it much easier to reuse another developer’s source code. For
this, visit their XDA kernel thread, and search for instructions regarding
where they’ve shared their source code. As an example of this method, let’s
look at developer g.lewarne‘s source code. His kernel
is titled Note2Core Kernel for Galaxy Note II N7100 / N7105 (LTE), and can be
found from http://forum.xda-developers.com/showthread.php?t=2001838 and the
source code from https://github.com/glewarne/Note2Core_v2_GT_N710x_Kernel.git
Setting up the host
PC and preparing source code
·
Install some essential linux packages from the
Linux terminal:
Extract the source
code
The file
you downloaded is a tar archive (like a zip file), so you need to extract it to
a convenient location. Let’s hit the linux shell-open a terminal window in
linux (Accessories->Terminal)
·
Create the directories for our kernel
compilation box:
·
Copy the tar.gz file from wherever you
downloaded it to, to this dir. You can use a file
explorer
GUI like Nautilus or Dolphin.
·
Extract the archive:
Set up the toolchain
A toolchain
is a set of programs which allow you to compile source code (any source code,
not just kernels). The toolchain is specific for the processor and hardware, so
we need a toolchain specific for Android and especially the Desire. If you’re a
semi advanced-pro user, you may consider compiling your own toolchain (See the Ganymedes’
guide for doing so). If compilation of kernels is all that you require,
fortunately for you, there is an easy way-the Android NDK – v7 (latest as of
now) is available in http://developer.android.com/sdk/ndk/index.html.
·
Get the NDK for Linux – android-ndk-r7-linux-x86.tar.bz2
mkdir -p ~/android/ndk
·
Now copy the NDK file to: ~/android/ndk
·
Extract it:
tar -jvxf android-ndk-r7-linux-x86.tar.bz2
·
Add the path for your toolchain to the env
variable:
gedit ~/.bashrc
·
At the end of the file, add this line:
·
Code:
Setting up kernel parameters
Kernels are
compiled with a program called gnu make, and use a set of configuration options
specified within a file called Makefile.
A vital
point to note is that kernels are compiled with a program called gcc (basically
the gnu C compiler), and our NDK itself has its own optimized version of gcc.
While compiling, we’re actually cross
compiling it (meaning compiling a binary package on a system which is
different from the actual system which is meant to run it- you’re compiling it
on your PC while it’s actually meant to run on your Desire).
This means
that when you compile it, you have to make sure that you compile it with the
NDK’s version of gcc instead of the system version.
Otherwise you end up with a kernel meant to run on your pc, duh! Specifying
which gcc to use is by the CROSS_COMPILE variable.
You can set it up with this command:
·
Code:
Note the
hyphen (-) at the end, and do not forget to include it! At compilation time,
system will actually use this variable to find all the programs it needs. Eg:
The path for gcc will become arm-linux-androideabi-gcc
We can
compile kernels with many different options, like with ext4 support, or
without;
ext4 support as part of the kernel zImage (in which case it
makes the kernel larger), or as a loadable module (of the form somename.ko,
which is loaded at init.d/init.rc with the command insmodmodulename.ko)
We specify
the exact options we require with the help of a useful configuration program
calledmenuconfig
(which as the name suggests, is a menu for configuration of make options).
Note that all make commands must be executed within the
directory bravo_2.6.35_gb-mr.
This produces a .config file (used by the menuconfig)
containing essential parameters to produce a booting kernel for the Desire.
To run the
defconfig on device. Need to know the name of the script which runs defconfig.
Get the
name by inspecting the names of the files in [kernel source folder]/arch/arm/configs.
Each file is renamed as .config
file.
Eg: to run a defconfig for Note2, you would type:
Note: There
is a simpler way to get the basic .config file, and this is to get it from a
running kernel built by someone else. You can extract the .config from a
running kernel with these commands:
Exit menuconfig.
Edit your
main Makefile (the Makefile that resides in the root folder of the kernel
source tree), and change the CROSS_COMPILE variable
to point to your toolchain. The Makefile also has a variable for ARCH, which by
default is arm. Once you set both of these, you can compile by simply
executing:
Compiling:
The basic command is:
The -j4 specifies the number of jobs to execute per
operation.
(or)
Compile simply by running:
Distributing Kernel to Users
At the end of compilation, it
generates files named zImage, and various .ko files. Copy them from their
default location to a zip file. So, let’s say that you have extracted an
existing kernel zip to the location ~/flashable, then the file structure should
be like this:
Now after every compilation of the kernel, execute these
commands from where you executed make:
Kernel Compilation Errors
·
Treat
warnings as errors
Solved by removing
the string “-Werror” from all Makefiles of the file which failed to compile.
Some people had said that the real error (Array out of bounds warning) was
because of gcc optimizations. But putting -O2 to -O0 didntdo a thing.
·
No of
jobs - ought not to exceed 50.
“warning:
variable set but not used [-Wunused-but-set-variable]“-Look at KBUILD_CFLAGS in
the main Makefile. Add -Wno-error=unused-but-set-variable to the existing set
of flags.
·
Werror
Make all
warnings into hard errors. Source code which triggers warnings will be
rejected. w Inhibit all warning
messages. If you’re familiar with C code and like to fix stuff, rather than
ignoring potential bugs, use this only as a last resort- A ‘brahmastram’ (most
powerful weapon in your time of gravest need) as the epics would say.
Werror Make all
warnings into errors.
Modifying Kernel
source code on the fly – Applying Kernel Patches
Patches to the kernel are applied
via patch files. Patch files are simple text files generated by the linux diff
program which takes two text files, compares them and writes the differences
(hence called diff) to another text file which by convention has the extension .patch
·
Example
patch
Following
is a patch containing my “Extended battery” fix with Sibere’sbattfix. I’ll
explain patching with this. Let’s understand the patch file. Open it up in any
text editor.
In the first line:
diff -rupNbasically describes the
command that was used to generate this patch. The -u means that the patch file
is something called a universal patch bravo_2.6.35_gb- mr/drivers/power/ds2784_battery.c was the original
file, and bravo_2.6.35_gb- mr.main//drivers/power/ds2784_battery.c
was the target file or file which contains the mod.
How to apply patch files
The command depends on where your current directory is. If
you’re in
~/android/kernel/bravo_2.6.35_gb-mr/
and your current directory contains the directory ‘drivers’,
apply this patch with this command:
patch -p1<extended_battfix.patch
If you’re within drivers, then you have to modify the
command :
patch -p2<extended_battfix.patch
Thus the Android open source operating system for mobile devices
was studied and a module was developed.
EMBEDDED AND REAL-TIME OPERATING SYSTEM
ECOS
AIM:
To study and
develop modules for the embedded operating systems such as eCos.
Real Time Operating System
Introduction
eCos
(embedded configurable operating system) is a free and open source real-time
operating system intended for embedded
systems and applications which need only one process with multiple threads. It is designed to be customizable to
precise application requirements of run-time performance and hardware needs. It
is implemented in C/C++ and has compatibility layers and APIs for POSIX and
µITRON.
Getting eCos
eCos is
hosted on OpenCores SVN. Use this command to download the complete package:
svn
co http://opencores.org/ocsvn/openrisc/openrisc/trunk/rtos/ecos-3.0
Here are the installed files.
Installing eCos
eCos uses
two tools to build and configure the system: configtool and ecosconfig.
ecosconfig is a handy command line program that allows to select the desired
eCos target and packages. configtool is
a windowed application that provides a clear and intuitive environment to
adjust all of the possible configuration options.
eCos configuration tools
The eCos configuration tools are maintained
by eCosCentric and can be downloaded from their
web page. The pre-built binary of configtool can be downloaded using the
following command:
Unpack and
copy to /usr/local/bin directory.
Building ecosconfig
ecosconfig
needs to be built from scratch. In order to build ecosconfig, go to the
ecos-3.0
directory
downloaded from SVN. Execute the following command:
./host/configure
The
execution stops after a few seconds showing this error messsage.
Fixing the tcl/tk
installation
We will
start by adding the following packages:
sudo
apt-get install tcl8.4-dev
sudo
apt-get install tk8.4-de
The
configure script looks for the tclConfig.sh
and tkConfig.sh files in the
directory /usr/local/lib.
Let's copy
the files to this directory and rerun the script.
This time the configuration script finishes without errors.
We are ready to build the ecosconfig
sudo make install
Both ecosconfig and configtool
require environmental variable ECOS_REPOSITORY. The variable must point to the
packages directory, inside ecos-3.0 tree.
Add this
line in our .bashrc file:
export
ECOS_REPOSITORY=/opt/home/svan/OpenRISC/ecos/ecos-3.0/packages
Configuring eCos for OpenRISC
ecosconfig new orpsoc
The default
configuration fits the ORPSoC port for ordb2 reference platform. It assumes
that hardware multiplication and division are implemented. Floating point
variables are handled by software. System clock runs at 50 MHz. If we are using
MinSoC, or ORPSoC with different configuation, we need to alter the settings:
configtool ecos.ecc
Let's
take a look at the current setup.
OpenRISC
System-on-Chip:
Do not make
any changes for the Atlys board, just save the ecc file. It is always a good
idea to check for possible conflicts by running:
ecosconfig check
Building eCos with tests
ecosconfig tree
make
make tests
Writing programs with eCos
It is now
possible to write programs linked with eCos. The most simple hello world
program
To compile
the program, use gcc with the following flags:
or32-elf-gcc
-g
-O2
-nostdlib
-install/include
-Linstall/lib
-Tinstall/lib/target.ld
examples/hello.c
-o hello.elf
Connecting a serial terminal
We are ready to load and run the Hello World program but
before we do, we have to connect a serial terminal to see the output from the
program. We use gtkterm with the following setup.
Running eCos on the
Atlys board
The most
convenient way is to run the program using GDB debugger. First, start
or_debug_proxy:
./or_debug_proxy
-r 50001
In another terminal start the GDB debugger.
or32-elf-gdb hello.elf
Connect to the target and load and run the program.
target remote :50001
load
Output on the serial
terminal:
More examples
The Hello World program is not the most interesting program
to run in a real time operating system. There are some more programs found in
the examples directory.
Output from the two
threads program:
RESULT
Thus the
embedded and real time operating systems such as eCos has been studied and modules has been developed
successfully.
DEVELOPMENT OF A REASONABLY SIZED DYNAMICALLY LOADABLE KERNEL MODULE
FOR LINUX KERNEL
AIM
To develop a
reasonably sized dynamically loadable kernel module for linux kernel.
Reasons for compiling
a custom kernel
·
The kernel need to be compiled in a special way
that the official kernel is not compiled in (for example, with some
experimental feature enabled).
·
Attempt
and debug a problem in the stock Ubuntu kernel for which it have to be filed or
will file a bug report.
·
Hardware stock of Ubuntu kernel does not support.
Reasons for NOT
compiling a custom kernel
·
There is a need to compile a special driver. For
this, it is necessary to install the linux-headers packages.
To install a new kernel without compilation,
we can use Synaptic, search for linux-
image and select the kernel
version you want to install.
An easier way is to click on
System > Administration > Update Manager, then click on the Check button,
and finally click on Apply all updates including the kernel.
Tools needed
To
start, there is a need to install a few
packages. The exact commands to install those packages depend on which release
you are using:
·
Hardy
(8.04):
sudo
apt-get install linux-kernel-devel fakeroot kernel-wedge build-essential
Note:
The package makedumpfile is not available in Hardy.
·
Lucid
(10.04):
sudo apt-get
install fakeroot build-essential crash kexec-tools makedumpfile kernel- wedge sudo apt-get build-dep linux sudo
apt-get install git-core libncurses5 libncurses5-dev libelf-dev asciidoc
binutils-dev
Get the kernel source
There are a
few ways to obtain the Ubuntu kernel source:
A) Use git
·
Use git (detailed instructions on it can be
found in the Kernel Git Guide) - This is for users who always want to stay in
sync with the latest Ubuntu kernel source.
The git
repository does not include necessary control files, so you must build them by:
fakeroot debian/rules clean
B) Download the
source archive
·
Download the source archive - This is for users
who want to rebuild the standard Ubuntu packages with additional patches. Note
that this will almost always be out of date compared to the latest development
source, so you should use git (option A) if you need the latest patches.
To
install the build dependencies and extract the source (to the current
directory):
Ubuntu Hardy (8.04)
sudo
apt-get build-dep --no-install-recommends --only-source linux
apt-get
source --only-source linux
·
Ubuntu modules source may also be needed if you
plan to enable PAE and 64 GiB support in the kernel for 32-bit Hardy (8.04). The
Ubuntu supplied modules may not be compatible with a PAE enabled kernel.
sudo
apt-get build-dep --no-install-recommends linux-ubuntu-modules-$(uname -r)
apt-get
source linux-ubuntu-modules-$(uname -r)
·
The source will be downloaded to a subdirectory
inside the current directory.
Ubuntu Karmic Koala (9.10) and newer
releases
sudo
apt-get build-dep --no-install-recommends linux-image-$(uname -r)
apt-get
source linux-image-$(uname -r)
·
The source will be downloaded to the current
directory (for Lucid, at least) as a trio of files (.orig.tar.gz, .diff.gz, and
.dsc) and a sub-directory. For instance, if uname -r returns 2.6.32-25-generic,
you'll obtain linux_2.6.32.orig.tar.gz, linux_2.6.32-25.44.diff.gz,
linux_2.6.32-25.44.dsc and the sub-directory linux-2.6.32.
C) Download the
source package
·
Download the source package (detailed
instructions are further down this page under Alternate Build Method: The
Old-Fashioned Debian Way) - This is for users who simply want to modify, or
play around with, the Ubuntu-patched kernel source. Again, this will not be the
most up-to- date (use option A/git if you need the latest source). Please be
aware this is NOT the same as option B.
Modify the source for
your needs
The stock Ubuntu configs
are located in debian/config/ARCH/ where ARCH is the architecture you are
building for (Starting with Jaunty this debian.master/config/ARCH/). In this
directory there are several files. The config file is the base for all targets
in that architecture. Then there are several config.FLAVOUR files that contain
options specific to that target. For example, here are the files for 2.6.20,
i386:
If there is no config files under
debian/config, find them in your /boot directory (for instance,
/boot/config-2.6.22-14-generic) otherwise you should check to see if an
alternate location has been specified within debian/debian.env of your kernel
source directory.
If
there is a need to change a config
option, simply modify the file that contains the option. If you modify just the
config file, it will affect all targets for this architecture. If you modify
one of the target files, it only affects that target.
After
applying a patch, or adjusting the configs, it is always best to regenerate the
config files to ensure they are consistent. There is a helper command for this.
To regenerate all architectures run:
debian/rules
updateconfigs
To update one architecture, run:
debian/scripts/misc/oldconfig
ARCH
Note: If there is no debian/ directory
after using apt-get source, use dpkg-source -x *dsc to extract the sources
properly.
For
these two commands to work, you need to give the scripts in the
debian/scripts/misc and debian/scripts directories execute permission with the
following command:
chmod
-R u+x debian/scripts/*
Build the kernel
(when source is from git repository, or from apt-get source):
To
build the kernel(s) is very simple. Depending on your needs, you may want to
build all the kernel targets, or just one specific to your system. However, you
also want to make sure that you do not clash with the stock kernels.
Note:
Though these outside instructions include making a separate and unique branch
of the kernel, unlike here, they include thorough explanations of all necessary
steps from start to finish.
·
Oneiric (11.10) Kernel 3.2 :
http://blog.avirtualhome.com/2012/01/13/compile-linux-kernel-3-2-for-ubuntu-11-10/
·
Oneiric (11.10) :
http://blog.avirtualhome.com/2011/10/28/how-to-compile-a-new-ubuntu-11-10-oneiric-kernel/
·
Maverick on Lucid (10.04):
http://blog.avirtualhome.com/2010/07/14/how-to-compile-a-
ubuntu-2-6-35-kernel-for-lucid/
·
Lucid (10.04):
http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-
kernel/
These instructions are specific to the
git-tree and for the source downloaded via apt-get source, not when downloading the linux-source package from kernel.org
Use
this command to build all targets for the architecture you are building on:
fakeroot debian/rules clean
AUTOBUILD=1 fakeroot debian/rules
binary-debs
debian/rules clean creates debian/control,
debian/changelog, and so on from
debian.<branchname>/*
(e.g. debian.master).
It is necessary in git trees following git
commit 3ebd3729ce35b784056239131408b9a72b0288ef
"UBUNTU: [Config] Abstract the debian
directory".
The
AUTOBUILD environment variable triggers special features in the kernel build.
First, it skips normal ABI checks (ABI is the binary compatibility). It can do
this because it also creates a unique ABI ID. If you used a git repo, this
unique ID is generated from the git HEAD SHA. If not, it is generated from the
uuidgen program (which means every time you execute the debian/rules build, the
UUID will be different!). Your packages will be named using this ID. (Note that
in Intrepid and newer, you will need skipabi=true to skip ABI checks.)
To
build a specific target, use this command:
fakeroot debian/rules clean
AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules
binary-FLAVOUR
Where FLAVOUR is one of the main flavours of
the kernel (e.g. generic)
To build one of the custom flavours (found
in debian/binary-custom.d/), use:
fakeroot debian/rules clean
AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules
custom-binary-FLAVOUR
·
If there are more than one processor or more than one core,
it can speed things up by
running
concurrent compile commands. Prepend CONCURRENCY_LEVEL=2 for two
processors or
two cores; replace '2' with whatever number suits your hardware setup (for Gutsy and later, you can alternatively use
DEB_BUILD_OPTIONS=parallel=2). fakeroot debian/rules clean
DEB_BUILD_OPTIONS=parallel=2
AUTOBUILD=1 NOEXTRAS=1 fakeroot
debian/rules binary-generic
·
If there are ABI errors, you can avoid the ABI
check with skipabi=true. For example,
fakeroot
debian/rules clean
DEB_BUILD_OPTIONS=parallel=2
AUTOBUILD=1 NOEXTRAS=1
skipabi=true
fakeroot
debian/rules binary-generic
·
To trigger a rebuild, remove the appropriate
stamp file from debian/stamps (e.g. stamp-build-server for the server flavour,
etc.). The debs are placed in your kernel directory's parent directory.
·
If needed, the Ubuntu modules source for Hardy
(8.04) can be built in a similar way.
cd
linux-ubuntu-modules-2.6.24-2.6.24
AUTOBUILD=1
fakeroot debian/rules binary-debs
Alternatively,
if you need to specify a different kernel than the running one, use cd linux- ubuntu-modules-2.6.24-2.6.24
AUTOBUILD=1
fakeroot debian/rules binary-debs KDIR=/path/to/kerneldir
·
If you get an error, try running this in the
kerneldir: (example for the generic flavour) cat debian/config/i386/config
debian/config/i386/config.generic > .config make prepare scripts.
Alternate Build
Method: The Old-Fashioned Debian Way :
The
new Ubuntu build system is great for developers, for people who need the
absolute latest bleeding-edge kernel, and people who need to build a diverse
set of kernels (several "flavours"). However it can be a little
complex for ordinary users. If you don't need the latest development sources,
there is a simpler way to compile your kernel from the linux-source package. As
suggested above, all you need for this is:
sudo
apt-get install linux-source device-tree-compiler#
device-tree-compiler is only needed
if you are targeting the PowerPC architecture
mkdir
~/src
cd
~/src
tar
xjvf /usr/src/linux-source-<version-number-here>.tar.bz2
cd
linux-source-<version-number-here
Now
you are in the top directory of a kernel source tree. Before building the
kernel, you must configure it. If you wish to re-use the configuration of your
currently-running kernel, start with
cp
-vi /boot/config-ùname -r` .config
Before
you run make menuconfig or make xconfig (which is what the next step tells you
to do), make sure you have the necessary packages:
sudo
apt-get install qt3-dev-tools libqt3-mt-dev # if you plan to use 'make xconfig'
sudo
apt-get install libncurses5 libncurses5-dev # if you plan to use 'make
menuconfig'
If
you would like to see what is different between your original kernel config and
the new one (and decide whether you want any of the new features), you can run:
make oldconfig
Since the 2.6.32 kernel, a new feature
allows you to update the configuration to only compile modules that are
actually used in your system:
make localmodconfig
Then,
regardless of whether you're re-using an existing configuration or starting
from scratch:
make
menuconfig # or "make xconfig"
If
you re-used the existing configuration, note that Ubuntu kernels build with
debugging information on, which makes the resulting kernel modules (*.ko files)
much larger than they would otherwise be.
To
turn this off, go into the config's "Kernel hacking"<!-- ; then,
under "Kernel debugging", --> and turn OFF "Compile the
kernel with debug info".
Now
you can compile the kernel and create the packages:
make
clean # only needed if you want to do a "clean" build
make
deb-pkg
You
can enable parallel make use make -j). Try 1+ number of processor cores, e.g. 3 if you have a dual core
processor:
make
-j3 deb-pkg
The
*.deb packages will be created in the parent directory of your Linux source
directory (in this example, they would be placed in ~/src because our Linux
source directory is ~/src/linux-source-<version-number-here>).
Install the new kernel
If
you want to see the Ubuntu splash screen (or use text mode) before you get to X
instead of just a black screen, you'll want to make sure the framebuffer driver
loads:
echo
vesafb | sudo tee -a /etc/initramfs-tools/modules
echo
fbcon | sudo tee -a /etc/initramfs-tools/modules
Now
that you've told initramfs-tools which modules it should include, and once the
build is complete, you can install the generated debs using dpkg:
sudo
dpkg -i linux-image-2.6.20-16-2be-k7_2.6.20-16_i386.deb
sudo
dpkg -i linux-headers-2.6.20-16-2be-k7_2.6.20-16_i386.deb
Similarly,
if you have built the Ubuntu module for Hardy (8.04) earlier, install them as
follows:
sudo
dpkg -i linux-ubuntu-modules-2.6.24-16-generic_2.6.24-16.23_i386.deb
sudo
dpkg -i linux-headers-lum-2.6.24-16-generic_2.6.24-16.23_i386.deb
If
you use modules from linux-restricted-modules, you will need to recompile this
against your new linux-headers package.
Note:
In response to the various comments in the remainder of this section: On Ubuntu
Precise (12.04) it appears that postinst DOES take care of the initramfs stuff.
After installing the package my new kernel booted just fine without following
any of the methods below. Someone please correct me if I'm mistaken.
Since
Ubuntu Lucid (10.04) the image postinst no longer runs the initramfs creation
commands. Instead, there are example scripts provided that will perform the
task. These scripts will work for official kernel images as well. For example:
First copy the default overlay
directory to your home directory:
$ cp -r /usr/share/kernel-package $HOME
Then
install the source of the kernel you are using currently, using the exact
package name, e.g.
$ cd
$
apt-get source linux-image-2.6.32-24-generic
which
will unpack the sources to $HOME/linux-2.6.32. Now copy the control scripts
into your newoverlay:
$cplinux-2.6.32/debian/control-scripts/{postinst,postrm,preinst,prerm}kernel package/pkg/image/
$ cp
linux-2.6.32/debian/control-scripts/headers-postinst
kernel-package/pkg/headers/
And
now you can execute make-kpkg with the additional command line option
--overlay-
dir=$HOME/kernel-package.
Rebuilding ''linux-restricted-modules''
The
linux-restricted-modules (l-r-m) package contains a number of non-DFSG-free
drivers (as well as some firmware and the ipw3945 wireless networking daemon)
which, in a perfect world, wouldn't have to be packaged separately, but which
unfortunately are not available under a GPL-compatible license. If you use any
of the hardware supported by the l-r-m package, you will likely find that your
system does not work as well after switching to a custom kernel. In this case
you should try to compile the l-r-m package.
Note:
you will need around 8 hours of compilation time and around 10 Gb of hard drive
space to compile all kernel flavours and restricted modules.
Further
note: There are no l-r-m or linux-restricted-modules packages in Lucid.
Speeding Up the Build
If
you have AMD64 machines available on your local net, they can still participate
in building 32-bit code; distcc seems to handle that automatically. However,
with distcc taking over all compiles by default, you will need to set HOSTCC so
that when kernel builds want to use the compiler on the host itself, they don't
end up distributing jobs to the 64-bit server. If you fail to do that, you'll
get link-compatibility failures between 64-bit and 32-bit code. My make-kpkg
command, with /usr/lib/ccache at the head of my $PATH, looks like:
MAKEFLAGS="HOSTCC=/usr/bin/gcc
CCACHE_PREFIX=distcc"
make-kpkg -- rootcmd fakeroot --initrd
--append-to-version=-suspend2 kernel-image kernel-headers kernel-source
Upgrading The Linux Kernel.
To
upgrade your kernel, run the commands below to update all packages and existing
kernels.
sudo
apt-get update && sudo apt-get dist-upgrade && sudo apt-get
autoremove
After
updating your machine, restart your machine. It’s always good to restart after
upgrading your system packages and kernel. Doing so allows for newer kernels to
be applied.
Next,
run the commands below to download Linux Kernel 3.12.7.
For 32-bit Machines,
run the commands below
For 64-bit System,
run the commands below
After downloading the version for
your system, run the commands below to install it.
sudo
dpkg -i *.deb
LOADABLE KERNEL MODULE
How to Create LKMs
Lets create
a basic loadable kernel module.
·
The names ‘init_module’ and ‘cleanup_module’ are
standard names for an LKM.
·
If you see closely then you will find that we
have used ‘printk’ instead of ‘printf’. This is because it is not a normal C
programming, its a kernel level programming which is a bit
different from
normal user level programming.
·
The headers module.h and kernel.h has to be
included to get the code compiled.
How to Compile LKMs
To compile the above LKM, I used the following Makefile :
obj-m
+= lkm.o
all:
sudo
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
sudo
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
After
the above successful compilation you will find a .ko file in the same directory
where the compilation took place.
This . ko file is the module that will be loaded in the kernel. modinfo
utility can be used to fetch the information about this module :
How LKM is Loaded
After
a successful compilation and creation of the module, now is the time to insert
it in the kernel so that it gets loaded on run time. The insertion of the
module can be achieved using the following two utilities :
·
modprobe
·
insmod
The difference between the two lies in the fact that ‘modprobe’ take
care of the fact that if the module in dependent on some other module then that
module is loaded first and then the main module is loaded. While the ‘insmod’
utility just inserts the module (whose name is specified) into the kernel. So
‘modprobe’ is a better utility but since our module is not dependent on any
other module so we will use ‘insmod’ only.
So, to insert the module, the
following command is used :
$
sudo insmod ./lkm.ko
if this command does not give any
error then that means the LKM is loaded successfully in the kernel. To unload
the LKM, the following command is used :
$
sudo rmmod lkm.ko
To
check that the module was loaded and unloaded correctly we can use the dmesg
utility which gives the last set of logs as logged by the kernel. You’ll see
the following two lines among all the other logs :
....
....
[
4048.333756] Welcome.....
[
4084.205143] Bye....
If
you go back to the code and see then you will realize that these are the logs
from the two functions in the code. So we see that one function was called when
the ‘insmod’ was called and the other function was called when the ‘rmmod’ was
called.
This was just a dummy LKM. In
this way many working LKM (that carry out meaningfutasks) work inside Linux
kernel.
Eg: hello.c:
The program requires you to
include -D options on your compile
command to work, because it
does not define some macros in
the source code, where the definitions belong.
Here is an improved world's
simplest LKM, hello.c
.
Compile this with the simple command:
$ gcc
-c -Wall -nostdinc -I /usr/src/linux/include hello.c
References:
2.
http://www.liberiangeek.net/2014/01/daily-ubuntu-tips-linux-kernel-3-12-7-released-
heres-how-to-upgrade-in-ubuntu/
7.
http://xda-university.com/as-a-developer/getting-started-building-a-kernel-from-
source
RESULT:
Thus the reasonably sized
dynamically loadable kernel module was developed successfully.
EDUCATIONAL OPERATING SYSTEMS MINIX
AIM
To study
educational operating systems such as minix and weenix and to develop a
reasonably sized modules.
Installing Minix3 in Virtualbox
1.
Start by downloading the installation disk from
a. http://www.minix3.org/iso/minix_R3.2.0-116fcea.iso.bz2
2.
Extract it to a location easy to find.
3.
Now open virtualbox and click the “New” button
in the main window.
4.
Click Next and choose a Name for the virtual
machine, I chose “Minix”. Under OS Type,
choose “Other”
And “Other/Unknown” and click Next.
5.
When setting memory for the virtual machine,
256MB should be enough.
6.
Create a new virtual disk by choosing VDI
(VirtualBox Disk Image) and click Next.
Because
we’ll only be using 2 GB I chose a “Fixed Size” disk image.
7.
Finish the disk creation setup and open up
virtualbox’s main window. Right click and
choose
settings on the new virtual machine we just created.
8.
Go to
Network in the settings window and click advanced. Choose PCNET-PCI II
(am79c970a) as network adapter.
9.
Go to storage and select the empty cdrom. Click
on the little cd icon on the top right, in the dropdown list, choose: “Choose a
virtual CD/DVD disk file..”. Browse your way to where you extracted the Minix iso file, select it,
and click “Open”.
10.
Click “OK” to close the settings window. Now you
are ready to power on the virtual
machine.
11.
Select the virtual machine and click “Start”
12.
A new windows appears, in the minix bootloader,
choose 1.
13.
The system boots up and prompts you with a log
in screen, type “root” to log in.
14.
Then type in “setup” to start the install
scripts.
15.
Type “Enter” to continue.
16.
If you have and us keyboard or know the us
mapping on your keyboard, just type “enter”
to continue. After that just follow the partition setup prompt.
17.
The next step is to partition the disk. Just
press “Enter” for setting up the partition automatically and follow the
instructions given on screen.
18.
After Minix3 setup script has finished copying
files to the new drive you get a choice of
which
ethernet chip. Just choose alternative 8. “AMD LANCE” by typing “Enter”.
19.
On the next prompt MINIX how it should configure
the network, just use the default choice (1. Automatically using DHCP) by
typing “Enter”. The setup is now done and you
get
back to the root shell. Type in “shutdown” to reboot the system.
20.After the
system shuts down, right click on the minix virtual machine and choose settings in the virtualbox main window.
Go to storage and select the cdrom again. Click at the cd icon to get the
dropdown menu up in the top right hand corner and choose “Remove disk from
virtual drive”. Click “OK” and start the virtual machine.
20.
When you
get the logon prompt, just type in “root” and press “enter”.
21.
MINIX3 is installed.
Installing MINIX in PCs
1. Getting MINIX
Download the
CD-ROM installer image from the http://www.minix3.org/download.
2. Preparation & Booting
Creating a bootable CD-ROM
a. Decompress
the downloaded file. You will get a CD-ROM image file with extension .iso.
b. The
.iso file is a bit-for-bit CD-ROM
image. Burn it to a CD-ROM disk to create a bootable MINIX
c. CD-ROM.
Please consult your CD burning program's documentation to learn how to burn ISO
d. images
to CD-ROM media.
e. If
you are running Windows XP and do not have a CD-ROM burning program, take a
look at http://alexfeinman.brinkster.net/isorecorder.htm
for a free one and use it to create a CD image.
Booting
from CD-ROM
a. Insert
the CD-ROM into your CD-ROM drive and boot the computer from it. If the
b. computer
boots from the hard disk instead of the CD-ROM, boot again and enter the BIOS
c. setup
program to change the order of boot devices, putting the CD-ROM before the hard
disk.
Partitioning your hard disk
Boot the
computer from your CD-ROM if you like and MINIX will start, but to do
anything useful, you have to create a
partition for it on your hard disk. But before partitioning, be sure to back
up your data.
Setting up a virtual machine
If you want to
run MINIX on a virtual machine instead of natively, see the installation
page for your VM of choice before
reading this page:
1. VMware
2. Qemu
(and KVM)
3. Bochs
4. Parallels
5. VirtualBox
6. Microsoft
VirtualPC 2007
3. Installation
Running the Setup script
a. When
the login prompt appears, login as
root. Press Enter when prompted for a
password.
b. To
start the installation of MINIX on the hard disk, type
Setup
a. After
this and all other commands, be sure to type ENTER (RETURN). When the
installation script ends a screen with a colon, hit ENTER to continue.
b. If
the screen suddenly goes blank, press CTRL-F3 to select software scrolling
(should only be needed on very old computers).
Select keyboard type
The us-swap keyboard interchanges the CAPS
LOCK and CTRL keys, as is conventional
on UNIX systems.
Create or select a partition for
MINIX
a. Start
MINIX disk partitioning.
b. Press
ENTER for the default action, which is an automated step-by-step guide to formatting
a disk partition for MINIX.
Select a disk
c. An
IDE controller may have up to four disks.
d. The
setup script will now look for each one. Just ignore any error messages.
e. When
the drives are listed, select one. and confirm your choice.
Select
a disk region
Now choose a region to install MINIX into.
You have three choices:
a. Select
a free region
b. Select
a partition to overwrite
c. Delete
a partition to free up space and merge with adjacent free space
d. For
choices (1) and (2), type the region number.
For (3) type:
e. Delete
then give the region number when asked. This region will be overwritten
and its previous contents lost forever.
Confirm your choices
a. Press
continues. If you do, the data in the selected region will be lost forever.
b. If
you are sure, type: yes and then
ENTER.
c. To
exit the setup script without changing the partition table, hit CTRL-C.
Select the size of /home
The
selected partition will be divided into three sub partitions: root,
/usr, and /home. The latter is for
your own personal files. Specify how much of the partition should be set aside
for your files. You will be asked to confirm your choice.
Select a block size
Disk block sizes
of 1-KB, 2-KB, 4-KB, and 8-KB are supported, but to use a size larger
than 4-KB you have to change a
constant and recompile the system. Use the default (4 KB) here.
Wait for files to be copied
Files will be
automatically copied from the CD-ROM to the hard disk. Every file will be
announced as it is copied.
Select your Ethernet chip
Select
Ethernet drivers to install. Network settings can be changed after
installation.
Restart
When the copying
is complete, MINIX is installed. Shut the
system down by typing:
shutdown
MINIX 3 Kernel API
1. Organization of Kernel Calls
A kernel call
means that a request is sent to a kernel where it is handled by one of the
kernel tasks. The details of assembling a request message, sending it to the
kernel and awaiting the response are conveniently hidden in a system library.
The header file of this library is src/include/minix/syslib.h
and its implementation is found in src/lib/syslib.
The actual
implementation of the kernel calls is defined in the SYSTEM kernel task. Suppose
that a program makes a sys_call()
system call. By convention, this call is transformed into a request message
with type SYS_CALL that is sent to
the kernel task SYSTEM. The SYSTEM task
handles the request in a function named do_call()
and returns the result.
The mapping of
kernel call numbers and handler functions is done during the SYSTEM
task's initialization response. src/kernel/system.c. The prototypes of
the handler functions are declared in src/kernel/system.h.
Their implementation is contained in separate files in the directory src/kernel/system/. These files are
compiled into the library /src/kernel/system/system.a
that is linked to the kernel.
The
kernel call numbers and their request and response parameters are defined
in src/include/minix/com.h.
Kernel calls all start with SYS_ and
all parameters that belong to the same kernel call share a common prefix.
2. Overview of kernel calls in MINIX 3
A
concise overview of the kernel calls in MINIX 3 is given in Table 1.
Kernel Call
|
Purpose
|
PROCESS MANAGEMENT
|
|
SYS_FORK
|
Fork a process; copy parent
process
|
SYS_EXEC
|
Execute a process; initialize
registers
|
SYS_EXIT
|
Exit a user process; clear
process slot
|
SYS_NICE
|
Change priority of a user
process
|
SYS_PRIVCTL
|
Change system process
privileges
|
SYS_TRACE
|
Trace or control process
execution
|
SYS_SETGRANT
|
Tell kernel about grant table
|
SYS_RUNCTL
|
Set/clear stop flag of a
process
|
SIGNAL HANDLING
|
|
SYS_KILL
|
Send a signal to a process
|
SYS_ENDKSIG
|
Tell kernel signal has been
processed
|
SYS_SIGSEND
|
Start POSIX-style signal
handler
|
SYS_SIGRETURN
|
Return POSIX-style signal
|
MEMORY MANAGEMENT
|
|
SYS_NEWMAP
|
Install new or updated memory map
|
SYS_MEMSET
|
Fill a physical memory area with a constant
pattern byte
|
SYS_VMCTL
|
(to be documented)
|
COPYING DATA
|
|
SYS_UMAP
|
Map virtual to physical address
|
SYS_VUMAP
|
Batch map virtual to physical addresses
|
SYS_VIRCOPY
|
Copy data using virtual addressing
|
SYS_PHYSCOPY
|
Copy data using physical
addressing
|
SYS_SAFECOPYFROM
|
Copy from a grant into own address space
|
SYS_SAFECOPYTO
|
Copy from own address space into a grant
|
SYS_VSAFECOPY
|
Handle vector with safe copy
requests
|
SYS_SAFEMEMSET
|
Fill a grant with a constant
pattern byte
|
DEVICE I/O
|
|
SYS_DEVIO
|
Read or write a single device
register
|
SYS_SDEVIO
|
Input or output an entire data
buffer
|
SYS_VDEVIO
|
Process vector with multiple
requests
|
SYS_IRQCTL
|
Set or reset an interrupt
policy
|
SYS_IOPENABLE
|
Give process I/O privilege
|
SYS_READBIOS
|
Copy from the BIOS area
|
SYSTEM CONTROL
|
|
SYS_ABORT
|
Abort MINIX: shutdown the
system
|
SYS_GETINFO
|
Get a copy system info or kernel data
|
SYS_SYSCTL
|
(to be documented)
|
CLOCK FUNCTIONALITY
|
|
SYS_SETALARM
|
Set or reset a synchronous
alarm timer
|
SYS_TIMES
|
Get process times, boot time
and uptime
|
SYS_STIME
|
Set boot time
|
SYS_VTIMER
|
Set or retrieve a process
virtual timer
|
PROFILING
|
|
SYS_SPROF
|
(to be documented)
|
SYS_CPROF
|
(to be documented)
|
SYS_PROFBUF
|
(to be documented)
|
Common Tests
Test Suite
a. Running
the test suite could take several hours.
b. At
the time of writing, not all tests pass on arm.
c. There
is a suite of tests which can be run to ensure that many of the software
features are working properly.
cd
/usr/tests/minix-posix
sh run
Real time clock, readclock, and rebooting
a. The
boards each have a hardware real time clock, similar to the CMOS clock on i386.
It
b. should
keep track of time while the board is running and between reboots.
c. Run
the date command to see the current date/time. Set the system date/time and run
date
d. again
to see the new, correct, date/time.
date
date
201309161200
date
e. Write
the date/time to the hardware real time clock.
readclock
-w
f. Run
readclock to read the hardware clock. Run date again to see that the correct
date/time have been read from the
hardware clock.
date
date
201301010000
date
readclock
date
g. Test
the reboot feature and ensure that the real time clock keeps working between
reboots.
reboot
h. Log
in and run the date command. It should have the right date/time.
date
References:
1.
http://www.netcrawlr.net/2012/09/installing-minix-3-in-virtualbox/
2.
http://wiki.minix3.org/DevelopersGuide/TestingMinixARM
RESULT
Thus the educational operating systems
such as minix and weenix has been studied and modules for them have been developed
successfully.
ANDROID OPEN SOURCE OPERATING SYSTEM FOR MOBILE DEVICES
AIM
To study and
develop modules for mobile devices using
android open source operating systems .
VirtualBox Installation
·
Download the Android 4.3 x86 iso from its Google
code page. As of this post, the build is
·
“Android-x86-4.3-20130725.iso”.
·
Install VirtualBox on Linux 64 bit Platform.
·
To install VirtualBox, do
sudo apt-get update
sudo apt-get install VirtualBox-4. 3
sudo apt-key add oracle_vbox.asc
Or
wget -q
http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc -O- | sudo
apt-key add –
Android Installation
In VirtualBox, create a new machine for Android.
1. Click
the “New” button. Enter a name for this virtual machine
2. Select
“Linux” for the Type and “Linux 2.6″ for the version.
3. Allocate a minimum of 2GB RAM for this VM.
4. Create
hard Disk space of new 16GB VDI image that dynamically expands.
5. Select
Networking with following requirements
·
Type: NAT
·
Adaptor: "Intel Pro/1000 MT Desktop
(82540EM)"
6. Select
Audio as Intel AC'97.
7. Choose
Storage Layout as
·
IDE Controller:
i.
CD Device
·
SATA Controller:
i.
Hard Disk
8. Under
the Storage section, select the CD/DVD drive slot and add the Android 4.3 iso
to the list.
Installing Android 4.3
Make sure
the VM boots from the ISO image.
•
On the boot screen, select "Installation - Install Android-x86 to
harddisk"
·
Choose "Create/Modify Partitions".
This takes you into cfdisk.
a. Choose
"[New]"
b. Choose "[Primary]"
c. Press
enter to accept the default partition size.
d. Choose
"[Bootable]"
e. Choose
"[Write]"
f. Type
"yes" to confirm writing.
g. Choose
"[Quit]"
Choose
to install on the sda1 device (Linux VBOX HARDDISK)
Choose
to format the drive "ext3"
·
Pick "Yes" to confirm formatting.
·
Pick "Yes" when it asks to install the
GRUB bootloader.
·
Pick "Yes" when it asks to mount
/system as read-write (this will be important later to Install the Google
apps).
·
Create a fake SD card when it prompts. I made
mine 2047MB (the maximum allowed).
·
Choose "<Reboot>"
Running Android 4.3 in VirtualBox
Reboot the
virtual machine. On the first bootup, it will take some time for the OS to load
and initialize. Subsequent boot up will be faster. Once you are in the Welcome
screen, follow the Setup wizard to setup Android 4.3.
At this point, you might want to disable the mouse
integration so that the mouse cursor will appear in the screen. This will make
the navigation process much easier.
While setting it up, it might not be able to detect any
Wi-Fi network. You can safely skip the Wi-Fi setup as it won’t affect your
Internet connection. It is also not necessary to sign in to your Google
account. It will take you to the Home screen once the setup is completed.
Modify Kernel Modules
Requirements to
modify android kernel modules
1. A
Linux installation (a PC on which a linux distro is installed) or Linux box
(May be a live cd or vmware like box). Any linux distro will do, but I assume
an Ubuntu installation to simplify the explanation.
2. A
toolchain-Either the Android NDK, or your own toolchain
3. Android
kernel source code for your device. This tutorial describes instruction for
both the Htc Desire and Samsung Galaxy Note N7100. With minor differences, the
method is practically the same for any Android device.
4. Familiarity
with the linux shell and basic linux commands.
Getting the source code
1. At
this point, you need to download the source code for your kernel. There are
generally, two ways to get kernel source code:
a. From
a compressed archive uploaded by the manufacturer of the device.
b. From
a git repository of another developer.
Choose the first method.
2. The
HTC Desire source is available from two kinds of resources-you can either get
it from htcdevs.com (official HTC Dev site), or from source code uploaded from
someone else. Assume we’re working on the official HTC GB source code. So
download bravo_2.6.35_gb-mr.tar.gz from htcdevs.com.
3. In
case, you’re working on a Samsung kernel, you can get your source code from
http://opensource.samsung.com/.
a. 4.
In many cases, it much easier to reuse another developer’s source code. For
this, visit their XDA kernel thread, and search for instructions regarding
where they’ve shared their source code. As an example of this method, let’s
look at developer g.lewarne‘s source code. His kernel
is titled Note2Core Kernel for Galaxy Note II N7100 / N7105 (LTE), and can be
found from http://forum.xda-developers.com/showthread.php?t=2001838 and the
source code from https://github.com/glewarne/Note2Core_v2_GT_N710x_Kernel.git
Setting up the host
PC and preparing source code
·
Install some essential linux packages from the
Linux terminal:
Extract the source
code
The file
you downloaded is a tar archive (like a zip file), so you need to extract it to
a convenient location. Let’s hit the linux shell-open a terminal window in
linux (Accessories->Terminal)
·
Create the directories for our kernel
compilation box:
·
Copy the tar.gz file from wherever you
downloaded it to, to this dir. You can use a file
explorer
GUI like Nautilus or Dolphin.
·
Extract the archive:
Set up the toolchain
A toolchain
is a set of programs which allow you to compile source code (any source code,
not just kernels). The toolchain is specific for the processor and hardware, so
we need a toolchain specific for Android and especially the Desire. If you’re a
semi advanced-pro user, you may consider compiling your own toolchain (See the Ganymedes’
guide for doing so). If compilation of kernels is all that you require,
fortunately for you, there is an easy way-the Android NDK – v7 (latest as of
now) is available in http://developer.android.com/sdk/ndk/index.html.
·
Get the NDK for Linux – android-ndk-r7-linux-x86.tar.bz2
mkdir -p ~/android/ndk
·
Now copy the NDK file to: ~/android/ndk
·
Extract it:
tar -jvxf android-ndk-r7-linux-x86.tar.bz2
·
Add the path for your toolchain to the env
variable:
gedit ~/.bashrc
·
At the end of the file, add this line:
·
Code:
Setting up kernel parameters
Kernels are
compiled with a program called gnu make, and use a set of configuration options
specified within a file called Makefile.
A vital
point to note is that kernels are compiled with a program called gcc (basically
the gnu C compiler), and our NDK itself has its own optimized version of gcc.
While compiling, we’re actually cross
compiling it (meaning compiling a binary package on a system which is
different from the actual system which is meant to run it- you’re compiling it
on your PC while it’s actually meant to run on your Desire).
This means
that when you compile it, you have to make sure that you compile it with the
NDK’s version of gcc instead of the system version.
Otherwise you end up with a kernel meant to run on your pc, duh! Specifying
which gcc to use is by the CROSS_COMPILE variable.
You can set it up with this command:
·
Code:
Note the
hyphen (-) at the end, and do not forget to include it! At compilation time,
system will actually use this variable to find all the programs it needs. Eg:
The path for gcc will become arm-linux-androideabi-gcc
We can
compile kernels with many different options, like with ext4 support, or
without;
ext4 support as part of the kernel zImage (in which case it
makes the kernel larger), or as a loadable module (of the form somename.ko,
which is loaded at init.d/init.rc with the command insmodmodulename.ko)
We specify
the exact options we require with the help of a useful configuration program
calledmenuconfig
(which as the name suggests, is a menu for configuration of make options).
Note that all make commands must be executed within the
directory bravo_2.6.35_gb-mr.
This produces a .config file (used by the menuconfig)
containing essential parameters to produce a booting kernel for the Desire.
To run the
defconfig on device. Need to know the name of the script which runs defconfig.
Get the
name by inspecting the names of the files in [kernel source folder]/arch/arm/configs.
Each file is renamed as .config
file.
Eg: to run a defconfig for Note2, you would type:
Note: There
is a simpler way to get the basic .config file, and this is to get it from a
running kernel built by someone else. You can extract the .config from a
running kernel with these commands:
Exit menuconfig.
Edit your
main Makefile (the Makefile that resides in the root folder of the kernel
source tree), and change the CROSS_COMPILE variable
to point to your toolchain. The Makefile also has a variable for ARCH, which by
default is arm. Once you set both of these, you can compile by simply
executing:
Compiling:
The basic command is:
The -j4 specifies the number of jobs to execute per
operation.
(or)
Compile simply by running:
Distributing Kernel to Users
At the end of compilation, it
generates files named zImage, and various .ko files. Copy them from their
default location to a zip file. So, let’s say that you have extracted an
existing kernel zip to the location ~/flashable, then the file structure should
be like this:
Now after every compilation of the kernel, execute these
commands from where you executed make:
Kernel Compilation Errors
·
Treat
warnings as errors
Solved by removing
the string “-Werror” from all Makefiles of the file which failed to compile.
Some people had said that the real error (Array out of bounds warning) was
because of gcc optimizations. But putting -O2 to -O0 didntdo a thing.
·
No of
jobs - ought not to exceed 50.
“warning:
variable set but not used [-Wunused-but-set-variable]“-Look at KBUILD_CFLAGS in
the main Makefile. Add -Wno-error=unused-but-set-variable to the existing set
of flags.
·
Werror
Make all
warnings into hard errors. Source code which triggers warnings will be
rejected. w Inhibit all warning
messages. If you’re familiar with C code and like to fix stuff, rather than
ignoring potential bugs, use this only as a last resort- A ‘brahmastram’ (most
powerful weapon in your time of gravest need) as the epics would say.
Werror Make all
warnings into errors.
Modifying Kernel
source code on the fly – Applying Kernel Patches
Patches to the kernel are applied
via patch files. Patch files are simple text files generated by the linux diff
program which takes two text files, compares them and writes the differences
(hence called diff) to another text file which by convention has the extension .patch
·
Example
patch
Following
is a patch containing my “Extended battery” fix with Sibere’sbattfix. I’ll
explain patching with this. Let’s understand the patch file. Open it up in any
text editor.
In the first line:
diff -rupNbasically describes the
command that was used to generate this patch. The -u means that the patch file
is something called a universal patch bravo_2.6.35_gb- mr/drivers/power/ds2784_battery.c was the original
file, and bravo_2.6.35_gb- mr.main//drivers/power/ds2784_battery.c
was the target file or file which contains the mod.
How to apply patch files
The command depends on where your current directory is. If
you’re in
~/android/kernel/bravo_2.6.35_gb-mr/
and your current directory contains the directory ‘drivers’,
apply this patch with this command:
patch -p1<extended_battfix.patch
If you’re within drivers, then you have to modify the
command :
patch -p2<extended_battfix.patch
Thus the Android open source operating system for mobile devices
was studied and a module was developed.
EMBEDDED AND REAL-TIME OPERATING SYSTEM
ECOS
AIM:
To study and
develop modules for the embedded operating systems such as eCos.
Real Time Operating System
Introduction
eCos
(embedded configurable operating system) is a free and open source real-time
operating system intended for embedded
systems and applications which need only one process with multiple threads. It is designed to be customizable to
precise application requirements of run-time performance and hardware needs. It
is implemented in C/C++ and has compatibility layers and APIs for POSIX and
µITRON.
Getting eCos
eCos is
hosted on OpenCores SVN. Use this command to download the complete package:
svn
co http://opencores.org/ocsvn/openrisc/openrisc/trunk/rtos/ecos-3.0
Here are the installed files.
Installing eCos
eCos uses
two tools to build and configure the system: configtool and ecosconfig.
ecosconfig is a handy command line program that allows to select the desired
eCos target and packages. configtool is
a windowed application that provides a clear and intuitive environment to
adjust all of the possible configuration options.
eCos configuration tools
The eCos configuration tools are maintained
by eCosCentric and can be downloaded from their
web page. The pre-built binary of configtool can be downloaded using the
following command:
Unpack and
copy to /usr/local/bin directory.
Building ecosconfig
ecosconfig
needs to be built from scratch. In order to build ecosconfig, go to the
ecos-3.0
directory
downloaded from SVN. Execute the following command:
./host/configure
The
execution stops after a few seconds showing this error messsage.
Fixing the tcl/tk
installation
We will
start by adding the following packages:
sudo
apt-get install tcl8.4-dev
sudo
apt-get install tk8.4-de
The
configure script looks for the tclConfig.sh
and tkConfig.sh files in the
directory /usr/local/lib.
Let's copy
the files to this directory and rerun the script.
This time the configuration script finishes without errors.
We are ready to build the ecosconfig
sudo make install
Both ecosconfig and configtool
require environmental variable ECOS_REPOSITORY. The variable must point to the
packages directory, inside ecos-3.0 tree.
Add this
line in our .bashrc file:
export
ECOS_REPOSITORY=/opt/home/svan/OpenRISC/ecos/ecos-3.0/packages
Configuring eCos for OpenRISC
ecosconfig new orpsoc
The default
configuration fits the ORPSoC port for ordb2 reference platform. It assumes
that hardware multiplication and division are implemented. Floating point
variables are handled by software. System clock runs at 50 MHz. If we are using
MinSoC, or ORPSoC with different configuation, we need to alter the settings:
configtool ecos.ecc
Let's
take a look at the current setup.
OpenRISC
System-on-Chip:
Do not make
any changes for the Atlys board, just save the ecc file. It is always a good
idea to check for possible conflicts by running:
ecosconfig check
Building eCos with tests
ecosconfig tree
make
make tests
Writing programs with eCos
It is now
possible to write programs linked with eCos. The most simple hello world
program
To compile
the program, use gcc with the following flags:
or32-elf-gcc
-g
-O2
-nostdlib
-install/include
-Linstall/lib
-Tinstall/lib/target.ld
examples/hello.c
-o hello.elf
Connecting a serial terminal
We are ready to load and run the Hello World program but
before we do, we have to connect a serial terminal to see the output from the
program. We use gtkterm with the following setup.
Running eCos on the
Atlys board
The most
convenient way is to run the program using GDB debugger. First, start
or_debug_proxy:
./or_debug_proxy
-r 50001
In another terminal start the GDB debugger.
or32-elf-gdb hello.elf
Connect to the target and load and run the program.
target remote :50001
load
Output on the serial
terminal:
More examples
The Hello World program is not the most interesting program
to run in a real time operating system. There are some more programs found in
the examples directory.
Output from the two
threads program:
RESULT
Thus the
embedded and real time operating systems such as eCos has been studied and modules has been developed
successfully.
Subscribe to:
Posts (Atom)