This a list of answers to Frequently Asked Questions about
ELKS, also known as Linux-8086.
-
Can I start ELKS from DOS, like LOADLIN.EXE
does for Linux ?
-
My palmtop has a RAMdrive. Can ELKS
access it ? (When/if ELKS gets an msdos filesystem, that is)
-
Can I combine the boot and root floppies
?
ELKS is the Embeddable Linux Kernel Subset,
a project to build a small kernel subset of Linux (which will provide more
or less UNIX V7 functionality within the kernel) that can run on machines
with limited processor and memory resources. More information on the background,
goals and current status of the project can be found at the
ELKS home page.
The initial proposed targets are the Intel 8086 and eventually
the 286's 16-bit protected mode. A kernel that can run on this kind of hardware
is useful for embedded systems projects, for third world deployment where
80x86 x>0 machines are not easily available, and for use on various palmtops.
ELKS is intended to be a subset of true
Linux, and ought to be small enough to be understood by one person, so it
should be invaluable as a learning tool. ELKS recently entered the beta
development state and most of it's functionality is there.
Having said that, it is already able to
boot, provide virtual consoles, mount minix filesystems, provide basic serial
and parallel I/O, connect to another computer over a null-modem SLIP link.
Finally ELKS supports swapping to virtualy enlarge the system RAM.
Not yet. You need to use a standard Linux
machine, download the sources, and cross-compile to generate the 8086 target
code. Boot and root disk images are provided with the current version of
ELKS, but all they do is act as a platform for testing the system, and
very little can be done with them.
If you are interested in building a distribution around
ELKS, you are welcome.
The 8088 is identical to the 8086, except
it has an 8-bit external data bus instead of 16-bit (and thus is slower).
So yes, ELKS will run on it.
These are simply high-integration versions
of the 8088 and 8086 respectively, so yes, ELKS will run on them.
From a software viewpoint, these are simply
8088 and 8086 processors respectively, with the sole exception that the
AAD instruction can not be used with bases other than decimal on the V20
and V30, whereas it can be used with other bases on the 8088 and 8086 processors.
This difference will not prevent ELKS from running on these processors, and
it is believed that the kernel is not affected by this difference, but user
reports would be appreciated.
The primary site http://elks.sf.net
The primary site for Dev86 is
http://www.cix.co.uk/~mayday/ which is the best place to find the latest
version.
If you know of any others or wish to set one up, please
contact the maintainer.
Recent releases contain a conmpiled binary
kernel which most people whould be able to use for initial testing. You
should only need to compile your own if you wish to modify the kernel, or
change the configuration options. The file boot in images.zip can be written
to floppy with dd or RAWRITE.EXE to make a kernel boot disk.
If you want to compile your own kernel,
download dev86/Dev86-0.0.13.4.tar.gz and kernel/elks-0.0.67/elks-0.0.67.tar.gz
(or the latest versions) from linux.mit.edu, or one of the other sites.
Unpack Dev86 them into /usr/src (or any other convenient directory), and
elks into /usr/src/linux-86 then do...
tar -xvzf Dev86-0.0.13.tar.gz -C /usr/src
tar -xvzf elks-0.0.67.tar.gz -C /usr/src
The development environment will be created
in /usr/src/linux-86, and the kernel source in /usr/src/elks. Next you have
to build the development tools, which include the bcc compiler:
cd /usr/src/linux-86
make install
Next, compile the kernel:
cd /usr/src/elks
# Build kernel
make config
make dep
make
Make config works in the same way as the
main Linux kernel. The default configuration will work on almost all systems.
Don't change any of the options unless you know what you are doing.
(If you're used to building Linux kernels
with gcc, you'll be amazed at how quick this is! :-) The result is a floppy
disk image called "Image", which you can copy to a formatted floppy and
boot from.
dd if=Image of=/dev/fd0
or
make disk
You should now be able to boot with this
disk, but you won't get much further without a root floppy disk for it to
mount. You can either use the image file root provided in images.zip, or
make your own. You'll need to use bcc to compile an 'init' program and make
a root minix filesystem. This is explained further down.
Edit /usr/include/sys/vm86.h
and change...
#include <linux/vm86.h>
...to...
#include <asm/vm86.h>
...instead.
After the ELKS kernel has booted it will
run /bin/init. A real version of 'init' is being prepared for inclusion
in the tiny-utils package, also on linux.mit.edu. A very basic init and
login is included in the sysutils part of the elkscmd package which is distributed
with each release. The kernel code has recently been changed so that it
loads /bin/init instead of /bin/sh.
To install init and login compile them
both with...
bcc -0 -O -ansi -s init.c -o init
bcc -0 -O -ansi -s login.c -o login
-0
selects 8086 code generation,
-O
enables optimisation,
-ansi
enables ansi-style function prototypes (only), and
-s
strips symbols out of the binary.
...and copy them into the /bin directory
of your root disk. The login program requires an /etc/passwd and a /etc/group
file, and a /bin/sh (or other depending on the entry in /etc/passwd.
As of kernel 0.0.56 sash now works and
is being used as /bin/sh by most people. It can be found in elkscmd.tar.gz.
For best results copy /etc/passwd and /etc/group from a standard linux distribution
onto your root disk so that ls -l works okay, and /usr/lib/liberror.txt so
that sash error reporting works.
A version of ash is also included which
does work under ELKS, but is much larger, and may not work at all on machines
with <640K of memory.
For most people the root filesystem included
in images.zip should be ideal, and can be used to create a root disk under
Linux as follows:
dd if=root of=/dev/fd0 bs=8192
Under DOS, RAWRITE.EXE can be used instead.
You need to create a minix floppy containing
the appropriate bits and pieces. This file should contain init, login, and
sh in /bin/ and passwd and group in /etc/, as well as three ttys for init
in /dev/.
Note: /dev/tty is different to normal
Linux which uses (5,0)
mkdir /usr/src/root86 # make a directory
cd /usr/src/root86
mkdir dev # create directorys in it
cd dev
mknod tty1 c 4 0 # creatye the required devices
mknod tty2 c 4 1
mknod tty3 c 4 2
mknod fd0 b 3 128
cd ..
mkdir bin
cd bin
cp <path-to-elkscmd-init> init # copy in essential binaries
cp <path-to-elkscmd-login> login
cp <path-to-elkscmd-sash> sh
cd ..
mkdir etc
cd etc
cp <path-to-skeleton-passwd> passwd # add required files for login
cp <path-to-skeleton-group> group
cd ..
fdformat /dev/fd0H1440 # if floppy not yet formatted
mkfs.minix -n14 /dev/fd0 1440
mount -t minix /dev/fd0 /a # need a mount point "/a"
cp -pR /usr/src/root86/* /a
umount /a
Some distributions use /dev/fd0u1440 instead
of /dev/fd0H1440. You should removed passwords from the passwd file as they
are not yet suported, and make sure the shell entry for each user is /bin/sh
for future compatability.
Alternatively, if you have a 2.0.x kernel
and mount-2.5k, you can use the loopback filesystem to create a disk image
on your hard disk, and then dump it to floppy:
dd if=/dev/zero of=root.image bs=18k count=80
losetup /dev/loop0 root.image
mkfs -t minix /dev/loop0 1440
mount -t minix /dev/loop0 /a
...
umount /a
dd if=root.image of=/dev/fd0
As of ELKS 0.0.53 floppy sizes other than
1.44M now work. Just follow the above intructions substituting the appropriate
sizes in where required. However, because of the way 360K disks are written
by 1.2Meg drives, the instructions below must be followed if you are trying
to boot a machine with a 360K drive.
Preparing boot and root images to run
on a different machine requires a little care, especially if the target machine
has a 360K drive. 360K drives (5.25" DD) have 40-track heads, and 1.2MB
(5.25" HD) have 80-track heads. A 1.2MB drive can read 360K disks but not
reliably write them, since it will write magnetic tracks which are half
the width expected by a 360K drive.
One solution is to fit a 360K drive as
the second drive in your Linux PC - you can then format 360K disks with...
fdformat /dev/fd1d360
...and create filesystems as usual.
Otherwise, you will need to create a floppy
disk image file, transfer it to the PC which has the 360K drive (e.g. using
a serial cable), then use "rawrite" under DOS to recreate the disk from
the image file.
The 'Image' file can be written to any
type of floppy disk and will boot successfully, so all you need to do is
transfer the file and use 'rawrite' to make the target disk.
Root disks are now autodetected so you
no longer have to re-compile for disk sizes other than 1.44Mb.
You can prepare a 360K root image on a
larger drive - when you enter the mkfs command substitute '360' for the
size of the filesystem. Once you have copied the files to this disk, unmount
it, then you can create a disk image file from it:
dd if=/dev/fd0 of=root.image bs=1k count=360
This image can then be transferred to
the target and written out using 'rawrite' as before. If you use the loopback
filesystem this step is not necessary.
0.0.44 expected there to be 640K RAM available.
However if you do not have 640K the problems with DEF_INITSEG and DEF_SETUPSEG
have now been fixed in later versions so you will not have to change anything.
Version 0.0.62 boot disk was compiled
to use the second floppy drive as a root disk because the wait_for_keypress()
function was broken. You can get round this if you only have one floppy
drive by using a hex editor to change the root device no. in the image.
If you get an error about root disk mount
failing on device 03c0, load the boot image into a hex editor and look for
c003h somewhere near the start of the image and change it to 8003h. (c003h
is 03c0 in Intel's backwards byte ordering). This should work for any version,
but it is not clear whether the address of the byte to edit varies between
version. jose@cnct.com reports that
in 0.0.62 boot image, the two bytes are at 0adf - oade.
As of version 0.0.65 it is possible to
install ELKS root disk on a harddisk and then create a boot floppy that
uses this. There still some bugs but it is more usable than a root floppy.
First create a partition with fdisk. Any
version of fdisk will be able to do this, but the current root disk only
supports bd?1-4, which are primary partitions, and if you already have a
DOS primary partition you will not be able to make a second primary partition
with DOS fdisk. The version of fdisk included on the ELKS 0.0.67 root disk
is still young code, but seems to work fine on my system.
Having created the partition, boot ELKS
from boot and root floppies, and create a filesystem using mkfs. It is safe
to use ELKS fdisk to check you know the correct device name for the partition
you want to create the filesystem on. To create the filesystem type...
mkfs /dev/bd?? <size>
...where bd?? is the correct partition,
and size is the size of the partition in Kbyte blocks. <size> cannot
be more than 32M. E.g. To make a filesystem on the first partition on the
slave disk, which is a 20M partition type:
mkfs /dev/bdb1 20000
Now mount the partition on the /mnt mount
point by typing...
mount /dev/bd?? /mnt
...where bd?? is the correct partition.
The root directory of the new partition may look a bit corrupted and it
may not be possibly to use ls from /mnt. I am not sure why mkfs is generating
slightly corrupt filesystems, but I am working on it.
Create the essential directories on the
new filesystem as follows:
cd /mnt
mkdir bin dev etc home mnt root
mkdir usr usr/lib
mkdir var var/log var/run
mkdir /mnt/home/user?....
Now copy essential files. You will need
many more than these for a decent system but here are the essentials and
some of the more useful ones:
cd /bin
cp -v cp init getty login ls mount pwd sh umount /mnt/bin/
cd /etc
cp -v group passwd /mnt/etc/
cp /usr/lib/liberror.txt /mnt/usr/lib/
touch /mnt/var/run/utmp
Finally create the essentail devices:
cd /mnt/dev
for N in 0 1 2 3 ; do mknod tty$N c 4 $N ; done
mknod fd0 b 3 128
mknod fd1 b 3 192
for N in '' 1 2 3 4 ; do mknod bda$N b 3 $[$N+0] ; done
for N in '' 1 2 3 4 ; do mknod bdb$N b 3 $[$N+64] ; done
cd /
Now unmount the new partition with
umount /dev/bd??
You will now need to re-compile a new
kernel with the correct root device selected. To do this edit
include/linuxmt/config.h in the ELKS kernel sources, and change the
CFG_ROOTDEV from 0x380 to the device number of the partition. The last two
digits must be the minor number of the partition in hex. The minor number
can be found from the list above in the far right column. E.g. The minor
number for bdb3 is 67, which is 43 in hex, so the ROOT_DEV value is
0x343.
When you have done this, type...
make disk
...to build a new kernel floppy, and reboot
the ELKS machine with this new boot disk. The new root should mount, but
may give a warning, and the system come up as normal, but much faster than
from floppy. As before the root directory may be corrupted, but it should
be possible to change to other directories normally, and the system should
work otherwise normally.
There are two issues with building Dev86
on recent systems which are known to be a problem under RedHat 6.0.
-
Firstly a conflict with recent glibc
means that a FILE * can no longer be initialised as pointing to standard
IO. A fix is in the works for this problem.
-
The version of ar shipped with some
Linux systems can no longer deal with bcc format .o files. A new ar program
has been written for Dev86 and will be included in the next release. In
the meantime Greg Haerr has made
the new version available from the
ftp://microwindows.censoft.com/pub/microwindows/ar ftp server.
Errors similar to the following may be
experienced building elkscmd if Dev86 was not built correctly against a
recent kernel:
undefined symbol: _setsid
undefined symbol: _fchown
This is caused because the Dev86 did
not pick up the list of system calls from the current kernel source. A similar
problem can occur if Dev86 does not find the kernel include directories,
and build links to them in bcc's standard include directory:
ps.c:2.26: error: cannot find include file linuxmt/sched.h
The solution to both these problems is as follows:-
elkscmd should now build correctly.
Warnings similar to the following may
be experienced building elkscmd:
ld86: warning: _utmpname redefined in file /usr/local/bcc/lib/bcc/i86/libc.a(utnt.o); using definition in utent.o
These are caused because elkscmd contains
patched version of files from the standard C library. Once these patched
version have been well tested they will be integrated into libs, and removed
from Dev86.
Yes - by loading a kernel module you can
run ELKS binaries directly. This makes development of programs to run under
ELKS much less painful, since you can test them on your normal Linux system
(although they might not work under ELKS, if your program uses a kernel facility
which is not yet implemented).
cd /usr/src/linux-86/elksemu
make module
insmod binfmt_elks.o
Note that you will need to rerun the 'insmod'
each time you reboot. There are some sample bcc programs you can try in
/usr/src/linux-86/tests (such as a version of 'wc').
If when making the module you get an error
saying "modversions.h: no such file or directory" then you need to edit
the Makefile to remove the reference to this file, i.e.:
MODCFLAGS=-D__KERNEL__ -Wall -Wstrict-prototypes -O2 \
-fomit-frame-pointer -fno-strength-reduce -pipe \
-m486 -DCPU=486 -DMODULE -DMODVERSIONS
Yes. ELKS can boot inside dosemu 0.63.1.36
running under Linux 2.0.7, and probably other combinations as well. Make
sure your floppy drive is configured in /etc/dosemu.conf, and use
the -A flag to dos or xdos if necessary to force a floppy boot.
floppy { device /dev/fd0 threeinch }
Yes! Just like any other Open Source project,
ELKS can always use more volunteers. The system is quite simple relative
to Linux so even people with relatively little experience can make a useful
contribution.
ELKS is now managed using
Source Forge which is an extremely useful service offered by
VA Linux. In order to contribute to ELKS you will need to register
for an account on Source Forge. The ELKS project page on Source Forge can
be found here.
Some idea of jobs that have been identified
can be gained by looking at the Oustanding projects, and Bugs pages on the
main website. These pages are automatically generated from the TODO and
BUGS files in the kernel source tree.
Outside of the kernel there is alot of
work to be done to put together the linux 8086 distribution which uses ELKS
as its kernel. Most of the work involves porting existing utilities to run
under ELKS.
CVS is the revision control system used
to manage the source code of the elks kernel and the elkscmd package. You
can use CVS to obtain the very latest version of the source code, loook
through the revision history, and more experienced developers with accounts
can use it to commit changes they have made to the code.
ELKS CVS is now hosted on SourceForge.Net
so, for details on getting an account see the link on CVS from the
ELKS project page.
Most distributions of Linux now include
CVS, so you should first check your distribution to determine whether it
is an optional package that hasn't yet been installed. If that is the case,
you should install that package.
The latest version of CVS can be downloaded
from www.cvshome.org
if you need to upgrade, and a manual for CVS is available online at the
same site.
SourceForge.Net offer full anonymous CVS
services by default. Full information can be found on the CVS page linked
from the ELKS project page
on Source Forge.
Answers to these questions would be appreciated!
Steffen Gabel
has written a package which can do this called
BootELKS, and would very much like to hear from anyone who uses it,
or has problems.
> From: Bar-David Yedidya < @math.tau.ac.il="">
>
> Today I managed to combine root/boot disks using LILO. It just
> worked!
>
> I created /boot on the floppy, copied Image and boot.b to it,
> put in /etc (on the floppy) lilo.conf with this:
>
> boot=/dev/fd0
> compact
> image=/boot/Image
> label=lin16
>
> did lilo -r /mnt and Hopla!
>
> I didn't look at the kernel sources yet to compare the boot
> code of linux and linux-16, but I guess they act the same,
> and that's why lilo worked.
There are reports this broke under the
recent ELKS versions (>0.0.46?)
Note: Will this work on pre 386 machines
?
Chad Page is working on a single disk
system which should be in the next version.
This document is released under the terms
of the GNU General Public
Licence, version 2 only