215 lines
7.8 KiB
ReStructuredText
215 lines
7.8 KiB
ReStructuredText
=======================
|
|
ARM Linux 2.6 and upper
|
|
=======================
|
|
|
|
Please check <ftp://ftp.arm.linux.org.uk/pub/armlinux> for
|
|
updates.
|
|
|
|
Compilation of kernel
|
|
---------------------
|
|
|
|
In order to compile ARM Linux, you will need a compiler capable of
|
|
generating ARM ELF code with GNU extensions. GCC 3.3 is known to be
|
|
a good compiler. Fortunately, you needn't guess. The kernel will report
|
|
an error if your compiler is a recognized offender.
|
|
|
|
To build ARM Linux natively, you shouldn't have to alter the ARCH = line
|
|
in the top level Makefile. However, if you don't have the ARM Linux ELF
|
|
tools installed as default, then you should change the CROSS_COMPILE
|
|
line as detailed below.
|
|
|
|
If you wish to cross-compile, then alter the following lines in the top
|
|
level make file::
|
|
|
|
ARCH = <whatever>
|
|
|
|
with::
|
|
|
|
ARCH = arm
|
|
|
|
and::
|
|
|
|
CROSS_COMPILE=
|
|
|
|
to::
|
|
|
|
CROSS_COMPILE=<your-path-to-your-compiler-without-gcc>
|
|
|
|
eg.::
|
|
|
|
CROSS_COMPILE=arm-linux-
|
|
|
|
Do a 'make config', followed by 'make Image' to build the kernel
|
|
(arch/arm/boot/Image). A compressed image can be built by doing a
|
|
'make zImage' instead of 'make Image'.
|
|
|
|
|
|
Bug reports etc
|
|
---------------
|
|
|
|
Please send patches to the patch system. For more information, see
|
|
http://www.arm.linux.org.uk/developer/patches/info.php Always include some
|
|
explanation as to what the patch does and why it is needed.
|
|
|
|
Bug reports should be sent to linux-arm-kernel@lists.arm.linux.org.uk,
|
|
or submitted through the web form at
|
|
http://www.arm.linux.org.uk/developer/
|
|
|
|
When sending bug reports, please ensure that they contain all relevant
|
|
information, eg. the kernel messages that were printed before/during
|
|
the problem, what you were doing, etc.
|
|
|
|
|
|
Include files
|
|
-------------
|
|
|
|
Several new include directories have been created under include/asm-arm,
|
|
which are there to reduce the clutter in the top-level directory. These
|
|
directories, and their purpose is listed below:
|
|
|
|
============= ==========================================================
|
|
`arch-*` machine/platform specific header files
|
|
`hardware` driver-internal ARM specific data structures/definitions
|
|
`mach` descriptions of generic ARM to specific machine interfaces
|
|
`proc-*` processor dependent header files (currently only two
|
|
categories)
|
|
============= ==========================================================
|
|
|
|
|
|
Machine/Platform support
|
|
------------------------
|
|
|
|
The ARM tree contains support for a lot of different machine types. To
|
|
continue supporting these differences, it has become necessary to split
|
|
machine-specific parts by directory. For this, the machine category is
|
|
used to select which directories and files get included (we will use
|
|
$(MACHINE) to refer to the category)
|
|
|
|
To this end, we now have arch/arm/mach-$(MACHINE) directories which are
|
|
designed to house the non-driver files for a particular machine (eg, PCI,
|
|
memory management, architecture definitions etc). For all future
|
|
machines, there should be a corresponding arch/arm/mach-$(MACHINE)/include/mach
|
|
directory.
|
|
|
|
|
|
Modules
|
|
-------
|
|
|
|
Although modularisation is supported (and required for the FP emulator),
|
|
each module on an ARM2/ARM250/ARM3 machine when is loaded will take
|
|
memory up to the next 32k boundary due to the size of the pages.
|
|
Therefore, is modularisation on these machines really worth it?
|
|
|
|
However, ARM6 and up machines allow modules to take multiples of 4k, and
|
|
as such Acorn RiscPCs and other architectures using these processors can
|
|
make good use of modularisation.
|
|
|
|
|
|
ADFS Image files
|
|
----------------
|
|
|
|
You can access image files on your ADFS partitions by mounting the ADFS
|
|
partition, and then using the loopback device driver. You must have
|
|
losetup installed.
|
|
|
|
Please note that the PCEmulator DOS partitions have a partition table at
|
|
the start, and as such, you will have to give '-o offset' to losetup.
|
|
|
|
|
|
Request to developers
|
|
---------------------
|
|
|
|
When writing device drivers which include a separate assembler file, please
|
|
include it in with the C file, and not the arch/arm/lib directory. This
|
|
allows the driver to be compiled as a loadable module without requiring
|
|
half the code to be compiled into the kernel image.
|
|
|
|
In general, try to avoid using assembler unless it is really necessary. It
|
|
makes drivers far less easy to port to other hardware.
|
|
|
|
|
|
ST506 hard drives
|
|
-----------------
|
|
|
|
The ST506 hard drive controllers seem to be working fine (if a little
|
|
slowly). At the moment they will only work off the controllers on an
|
|
A4x0's motherboard, but for it to work off a Podule just requires
|
|
someone with a podule to add the addresses for the IRQ mask and the
|
|
HDC base to the source.
|
|
|
|
As of 31/3/96 it works with two drives (you should get the ADFS
|
|
`*configure` harddrive set to 2). I've got an internal 20MB and a great
|
|
big external 5.25" FH 64MB drive (who could ever want more :-) ).
|
|
|
|
I've just got 240K/s off it (a dd with bs=128k); thats about half of what
|
|
RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting
|
|
last week :-)
|
|
|
|
Known bug: Drive data errors can cause a hang; including cases where
|
|
the controller has fixed the error using ECC. (Possibly ONLY
|
|
in that case...hmm).
|
|
|
|
|
|
1772 Floppy
|
|
-----------
|
|
This also seems to work OK, but hasn't been stressed much lately. It
|
|
hasn't got any code for disc change detection in there at the moment which
|
|
could be a bit of a problem! Suggestions on the correct way to do this
|
|
are welcome.
|
|
|
|
|
|
`CONFIG_MACH_` and `CONFIG_ARCH_`
|
|
---------------------------------
|
|
A change was made in 2003 to the macro names for new machines.
|
|
Historically, `CONFIG_ARCH_` was used for the bonafide architecture,
|
|
e.g. SA1100, as well as implementations of the architecture,
|
|
e.g. Assabet. It was decided to change the implementation macros
|
|
to read `CONFIG_MACH_` for clarity. Moreover, a retroactive fixup has
|
|
not been made because it would complicate patching.
|
|
|
|
Previous registrations may be found online.
|
|
|
|
<http://www.arm.linux.org.uk/developer/machines/>
|
|
|
|
Kernel entry (head.S)
|
|
---------------------
|
|
The initial entry into the kernel is via head.S, which uses machine
|
|
independent code. The machine is selected by the value of 'r1' on
|
|
entry, which must be kept unique.
|
|
|
|
Due to the large number of machines which the ARM port of Linux provides
|
|
for, we have a method to manage this which ensures that we don't end up
|
|
duplicating large amounts of code.
|
|
|
|
We group machine (or platform) support code into machine classes. A
|
|
class typically based around one or more system on a chip devices, and
|
|
acts as a natural container around the actual implementations. These
|
|
classes are given directories - arch/arm/mach-<class> and
|
|
arch/arm/mach-<class> - which contain the source files to/include/mach
|
|
support the machine class. This directories also contain any machine
|
|
specific supporting code.
|
|
|
|
For example, the SA1100 class is based upon the SA1100 and SA1110 SoC
|
|
devices, and contains the code to support the way the on-board and off-
|
|
board devices are used, or the device is setup, and provides that
|
|
machine specific "personality."
|
|
|
|
For platforms that support device tree (DT), the machine selection is
|
|
controlled at runtime by passing the device tree blob to the kernel. At
|
|
compile-time, support for the machine type must be selected. This allows for
|
|
a single multiplatform kernel build to be used for several machine types.
|
|
|
|
For platforms that do not use device tree, this machine selection is
|
|
controlled by the machine type ID, which acts both as a run-time and a
|
|
compile-time code selection method. You can register a new machine via the
|
|
web site at:
|
|
|
|
<http://www.arm.linux.org.uk/developer/machines/>
|
|
|
|
Note: Please do not register a machine type for DT-only platforms. If your
|
|
platform is DT-only, you do not need a registered machine type.
|
|
|
|
---
|
|
|
|
Russell King (15/03/2004)
|