cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

arm.rst (7903B)


      1=======================
      2ARM Linux 2.6 and upper
      3=======================
      4
      5    Please check <ftp://ftp.arm.linux.org.uk/pub/armlinux> for
      6    updates.
      7
      8Compilation of kernel
      9---------------------
     10
     11  In order to compile ARM Linux, you will need a compiler capable of
     12  generating ARM ELF code with GNU extensions.  GCC 3.3 is known to be
     13  a good compiler.  Fortunately, you needn't guess.  The kernel will report
     14  an error if your compiler is a recognized offender.
     15
     16  To build ARM Linux natively, you shouldn't have to alter the ARCH = line
     17  in the top level Makefile.  However, if you don't have the ARM Linux ELF
     18  tools installed as default, then you should change the CROSS_COMPILE
     19  line as detailed below.
     20
     21  If you wish to cross-compile, then alter the following lines in the top
     22  level make file::
     23
     24    ARCH = <whatever>
     25
     26  with::
     27
     28    ARCH = arm
     29
     30  and::
     31
     32    CROSS_COMPILE=
     33
     34  to::
     35
     36    CROSS_COMPILE=<your-path-to-your-compiler-without-gcc>
     37
     38  eg.::
     39
     40    CROSS_COMPILE=arm-linux-
     41
     42  Do a 'make config', followed by 'make Image' to build the kernel
     43  (arch/arm/boot/Image).  A compressed image can be built by doing a
     44  'make zImage' instead of 'make Image'.
     45
     46
     47Bug reports etc
     48---------------
     49
     50  Please send patches to the patch system.  For more information, see
     51  http://www.arm.linux.org.uk/developer/patches/info.php Always include some
     52  explanation as to what the patch does and why it is needed.
     53
     54  Bug reports should be sent to linux-arm-kernel@lists.arm.linux.org.uk,
     55  or submitted through the web form at
     56  http://www.arm.linux.org.uk/developer/
     57
     58  When sending bug reports, please ensure that they contain all relevant
     59  information, eg. the kernel messages that were printed before/during
     60  the problem, what you were doing, etc.
     61
     62
     63Include files
     64-------------
     65
     66  Several new include directories have been created under include/asm-arm,
     67  which are there to reduce the clutter in the top-level directory.  These
     68  directories, and their purpose is listed below:
     69
     70  ============= ==========================================================
     71   `arch-*`	machine/platform specific header files
     72   `hardware`	driver-internal ARM specific data structures/definitions
     73   `mach`	descriptions of generic ARM to specific machine interfaces
     74   `proc-*`	processor dependent header files (currently only two
     75		categories)
     76  ============= ==========================================================
     77
     78
     79Machine/Platform support
     80------------------------
     81
     82  The ARM tree contains support for a lot of different machine types.  To
     83  continue supporting these differences, it has become necessary to split
     84  machine-specific parts by directory.  For this, the machine category is
     85  used to select which directories and files get included (we will use
     86  $(MACHINE) to refer to the category)
     87
     88  To this end, we now have arch/arm/mach-$(MACHINE) directories which are
     89  designed to house the non-driver files for a particular machine (eg, PCI,
     90  memory management, architecture definitions etc).  For all future
     91  machines, there should be a corresponding arch/arm/mach-$(MACHINE)/include/mach
     92  directory.
     93
     94
     95Modules
     96-------
     97
     98  Although modularisation is supported (and required for the FP emulator),
     99  each module on an ARM2/ARM250/ARM3 machine when is loaded will take
    100  memory up to the next 32k boundary due to the size of the pages.
    101  Therefore, is modularisation on these machines really worth it?
    102
    103  However, ARM6 and up machines allow modules to take multiples of 4k, and
    104  as such Acorn RiscPCs and other architectures using these processors can
    105  make good use of modularisation.
    106
    107
    108ADFS Image files
    109----------------
    110
    111  You can access image files on your ADFS partitions by mounting the ADFS
    112  partition, and then using the loopback device driver.  You must have
    113  losetup installed.
    114
    115  Please note that the PCEmulator DOS partitions have a partition table at
    116  the start, and as such, you will have to give '-o offset' to losetup.
    117
    118
    119Request to developers
    120---------------------
    121
    122  When writing device drivers which include a separate assembler file, please
    123  include it in with the C file, and not the arch/arm/lib directory.  This
    124  allows the driver to be compiled as a loadable module without requiring
    125  half the code to be compiled into the kernel image.
    126
    127  In general, try to avoid using assembler unless it is really necessary.  It
    128  makes drivers far less easy to port to other hardware.
    129
    130
    131ST506 hard drives
    132-----------------
    133
    134  The ST506 hard drive controllers seem to be working fine (if a little
    135  slowly).  At the moment they will only work off the controllers on an
    136  A4x0's motherboard, but for it to work off a Podule just requires
    137  someone with a podule to add the addresses for the IRQ mask and the
    138  HDC base to the source.
    139
    140  As of 31/3/96 it works with two drives (you should get the ADFS
    141  `*configure` harddrive set to 2). I've got an internal 20MB and a great
    142  big external 5.25" FH 64MB drive (who could ever want more :-) ).
    143
    144  I've just got 240K/s off it (a dd with bs=128k); thats about half of what
    145  RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting
    146  last week :-)
    147
    148  Known bug: Drive data errors can cause a hang; including cases where
    149  the controller has fixed the error using ECC. (Possibly ONLY
    150  in that case...hmm).
    151
    152
    1531772 Floppy
    154-----------
    155  This also seems to work OK, but hasn't been stressed much lately.  It
    156  hasn't got any code for disc change detection in there at the moment which
    157  could be a bit of a problem!  Suggestions on the correct way to do this
    158  are welcome.
    159
    160
    161`CONFIG_MACH_` and `CONFIG_ARCH_`
    162---------------------------------
    163  A change was made in 2003 to the macro names for new machines.
    164  Historically, `CONFIG_ARCH_` was used for the bonafide architecture,
    165  e.g. SA1100, as well as implementations of the architecture,
    166  e.g. Assabet.  It was decided to change the implementation macros
    167  to read `CONFIG_MACH_` for clarity.  Moreover, a retroactive fixup has
    168  not been made because it would complicate patching.
    169
    170  Previous registrations may be found online.
    171
    172    <http://www.arm.linux.org.uk/developer/machines/>
    173
    174Kernel entry (head.S)
    175---------------------
    176  The initial entry into the kernel is via head.S, which uses machine
    177  independent code.  The machine is selected by the value of 'r1' on
    178  entry, which must be kept unique.
    179
    180  Due to the large number of machines which the ARM port of Linux provides
    181  for, we have a method to manage this which ensures that we don't end up
    182  duplicating large amounts of code.
    183
    184  We group machine (or platform) support code into machine classes.  A
    185  class typically based around one or more system on a chip devices, and
    186  acts as a natural container around the actual implementations.  These
    187  classes are given directories - arch/arm/mach-<class> - which contain
    188  the source files and include/mach/ to support the machine class.
    189
    190  For example, the SA1100 class is based upon the SA1100 and SA1110 SoC
    191  devices, and contains the code to support the way the on-board and off-
    192  board devices are used, or the device is setup, and provides that
    193  machine specific "personality."
    194
    195  For platforms that support device tree (DT), the machine selection is
    196  controlled at runtime by passing the device tree blob to the kernel.  At
    197  compile-time, support for the machine type must be selected.  This allows for
    198  a single multiplatform kernel build to be used for several machine types.
    199
    200  For platforms that do not use device tree, this machine selection is
    201  controlled by the machine type ID, which acts both as a run-time and a
    202  compile-time code selection method.  You can register a new machine via the
    203  web site at:
    204
    205    <http://www.arm.linux.org.uk/developer/machines/>
    206
    207  Note: Please do not register a machine type for DT-only platforms.  If your
    208  platform is DT-only, you do not need a registered machine type.
    209
    210---
    211
    212Russell King (15/03/2004)