lastdragon/linux-kernel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Resguardo inicial

Browse Source
This commit is contained in:
lastdragon
2026-09-06 12:53:21 -06:00
parent 662efe3c2a
commit ad2088d178
94853 changed files with 43200404 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
linux-7.2.3/Documentation/arch/arm/arm.rst
+212
View File
@@ -0,0 +1,212 @@
=======================
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); that's 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> - which contain
the source files and include/mach/ to support the machine class.
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)
linux-7.2.3/Documentation/arch/arm/booting.rst
+237
View File
@@ -0,0 +1,237 @@
=================
Booting ARM Linux
=================
Author: Russell King
Date : 18 May 2002
The following documentation is relevant to 2.4.18-rmk6 and beyond.
In order to boot ARM Linux, you require a boot loader, which is a small
program that runs before the main kernel. The boot loader is expected
to initialise various devices, and eventually call the Linux kernel,
passing information to the kernel.
Essentially, the boot loader should provide (as a minimum) the
following:
1. Setup and initialise the RAM.
2. Initialise one serial port.
3. Detect the machine type.
4. Setup the kernel tagged list.
5. Load initramfs.
6. Call the kernel image.
1. Setup and initialise RAM
---------------------------
Existing boot loaders:
MANDATORY
New boot loaders:
MANDATORY
The boot loader is expected to find and initialise all RAM that the
kernel will use for volatile data storage in the system. It performs
this in a machine dependent manner. (It may use internal algorithms
to automatically locate and size all RAM, or it may use knowledge of
the RAM in the machine, or any other method the boot loader designer
sees fit.)
2. Initialise one serial port
-----------------------------
Existing boot loaders:
OPTIONAL, RECOMMENDED
New boot loaders:
OPTIONAL, RECOMMENDED
The boot loader should initialise and enable one serial port on the
target. This allows the kernel serial driver to automatically detect
which serial port it should use for the kernel console (generally
used for debugging purposes, or communication with the target.)
As an alternative, the boot loader can pass the relevant 'console='
option to the kernel via the tagged lists specifying the port, and
serial format options as described in
Documentation/admin-guide/kernel-parameters.rst.
3. Detect the machine type
--------------------------
Existing boot loaders:
OPTIONAL
New boot loaders:
MANDATORY except for DT-only platforms
The boot loader should detect the machine type its running on by some
method. Whether this is a hard coded value or some algorithm that
looks at the connected hardware is beyond the scope of this document.
The boot loader must ultimately be able to provide a MACH_TYPE_xxx
value to the kernel. (see linux/arch/arm/tools/mach-types). This
should be passed to the kernel in register r1.
For DT-only platforms, the machine type will be determined by device
tree. set the machine type to all ones (~0). This is not strictly
necessary, but assures that it will not match any existing types.
4. Setup boot data
------------------
Existing boot loaders:
OPTIONAL, HIGHLY RECOMMENDED
New boot loaders:
MANDATORY
The boot loader must provide either a tagged list or a dtb image for
passing configuration data to the kernel. The physical address of the
boot data is passed to the kernel in register r2.
4a. Setup the kernel tagged list
--------------------------------
The boot loader must create and initialise the kernel tagged list.
A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE.
The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag
has the size field set to '2' (0x00000002). The ATAG_NONE must set
the size field to zero.
Any number of tags can be placed in the list. It is undefined
whether a repeated tag appends to the information carried by the
previous tag, or whether it replaces the information in its
entirety; some tags behave as the former, others the latter.
The boot loader must pass at a minimum the size and location of
the system memory, and root filesystem location. Therefore, the
minimum tagged list should look::
+-----------+
base -> | ATAG_CORE | |
+-----------+ |
| ATAG_MEM | | increasing address
+-----------+ |
| ATAG_NONE | |
+-----------+ v
The tagged list should be stored in system RAM.
The tagged list must be placed in a region of memory where neither
the kernel decompressor nor initrd 'bootp' program will overwrite
it. The recommended placement is in the first 16KiB of RAM.
4b. Setup the device tree
-------------------------
The boot loader must load a device tree image (dtb) into system ram
at a 64bit aligned address and initialize it with the boot data. The
dtb format is documented at https://www.devicetree.org/specifications/.
The kernel will look for the dtb magic value of 0xd00dfeed at the dtb
physical address to determine if a dtb has been passed instead of a
tagged list.
The boot loader must pass at a minimum the size and location of the
system memory, and the root filesystem location. The dtb must be
placed in a region of memory where the kernel decompressor will not
overwrite it, while remaining within the region which will be covered
by the kernel's low-memory mapping.
A safe location is just above the 128MiB boundary from start of RAM.
5. Load initramfs.
------------------
Existing boot loaders:
OPTIONAL
New boot loaders:
OPTIONAL
If an initramfs is in use then, as with the dtb, it must be placed in
a region of memory where the kernel decompressor will not overwrite it
while also with the region which will be covered by the kernel's
low-memory mapping.
A safe location is just above the device tree blob which itself will
be loaded just above the 128MiB boundary from the start of RAM as
recommended above.
6. Calling the kernel image
---------------------------
Existing boot loaders:
MANDATORY
New boot loaders:
MANDATORY
There are two options for calling the kernel zImage. If the zImage
is stored in flash, and is linked correctly to be run from flash,
then it is legal for the boot loader to call the zImage in flash
directly.
The zImage may also be placed in system RAM and called there. The
kernel should be placed in the first 128MiB of RAM. It is recommended
that it is loaded above 32MiB in order to avoid the need to relocate
prior to decompression, which will make the boot process slightly
faster.
When booting a raw (non-zImage) kernel the constraints are tighter.
In this case the kernel must be loaded at an offset into system equal
to TEXT_OFFSET - PAGE_OFFSET.
In any case, the following conditions must be met:
- Quiesce all DMA capable devices so that memory does not get
corrupted by bogus network packets or disk data. This will save
you many hours of debug.
- CPU register settings
- r0 = 0,
- r1 = machine type number discovered in (3) above.
- r2 = physical address of tagged list in system RAM, or
physical address of device tree block (dtb) in system RAM
- CPU mode
All forms of interrupts must be disabled (IRQs and FIQs)
For CPUs which do not include the ARM virtualization extensions, the
CPU must be in SVC mode. (A special exception exists for Angel)
CPUs which include support for the virtualization extensions can be
entered in HYP mode in order to enable the kernel to make full use of
these extensions. This is the recommended boot method for such CPUs,
unless the virtualisations are already in use by a pre-installed
hypervisor.
If the kernel is not entered in HYP mode for any reason, it must be
entered in SVC mode.
- Caches, MMUs
The MMU must be off.
Instruction cache may be on or off.
Data cache must be off.
If the kernel is entered in HYP mode, the above requirements apply to
the HYP mode configuration in addition to the ordinary PL1 (privileged
kernel modes) configuration. In addition, all traps into the
hypervisor must be disabled, and PL1 access must be granted for all
peripherals and CPU resources for which this is architecturally
possible. Except for entering in HYP mode, the system configuration
should be such that a kernel which does not include support for the
virtualization extensions can boot correctly without extra help.
- The boot loader is expected to call the kernel image by jumping
directly to the first instruction of the kernel image.
On CPUs supporting the ARM instruction set, the entry must be
made in ARM state, even for a Thumb-2 kernel.
On CPUs supporting only the Thumb instruction set such as
Cortex-M class CPUs, the entry must be made in Thumb state.
linux-7.2.3/Documentation/arch/arm/cluster-pm-race-avoidance.rst
+533
View File
@@ -0,0 +1,533 @@
=========================================================
Cluster-wide Power-up/power-down race avoidance algorithm
=========================================================
This file documents the algorithm which is used to coordinate CPU and
cluster setup and teardown operations and to manage hardware coherency
controls safely.
The section "Rationale" explains what the algorithm is for and why it is
needed. "Basic model" explains general concepts using a simplified view
of the system. The other sections explain the actual details of the
algorithm in use.
Rationale
---------
In a system containing multiple CPUs, it is desirable to have the
ability to turn off individual CPUs when the system is idle, reducing
power consumption and thermal dissipation.
In a system containing multiple clusters of CPUs, it is also desirable
to have the ability to turn off entire clusters.
Turning entire clusters off and on is a risky business, because it
involves performing potentially destructive operations affecting a group
of independently running CPUs, while the OS continues to run. This
means that we need some coordination in order to ensure that critical
cluster-level operations are only performed when it is truly safe to do
so.
Simple locking may not be sufficient to solve this problem, because
mechanisms like Linux spinlocks may rely on coherency mechanisms which
are not immediately enabled when a cluster powers up. Since enabling or
disabling those mechanisms may itself be a non-atomic operation (such as
writing some hardware registers and invalidating large caches), other
methods of coordination are required in order to guarantee safe
power-down and power-up at the cluster level.
The mechanism presented in this document describes a coherent memory
based protocol for performing the needed coordination. It aims to be as
lightweight as possible, while providing the required safety properties.
Basic model
-----------
Each cluster and CPU is assigned a state, as follows:
- DOWN
- COMING_UP
- UP
- GOING_DOWN
::
+---------> UP ----------+
| v
COMING_UP GOING_DOWN
^ |
+--------- DOWN <--------+
DOWN:
The CPU or cluster is not coherent, and is either powered off or
suspended, or is ready to be powered off or suspended.
COMING_UP:
The CPU or cluster has committed to moving to the UP state.
It may be part way through the process of initialisation and
enabling coherency.
UP:
The CPU or cluster is active and coherent at the hardware
level. A CPU in this state is not necessarily being used
actively by the kernel.
GOING_DOWN:
The CPU or cluster has committed to moving to the DOWN
state. It may be part way through the process of teardown and
coherency exit.
Each CPU has one of these states assigned to it at any point in time.
The CPU states are described in the "CPU state" section, below.
Each cluster is also assigned a state, but it is necessary to split the
state value into two parts (the "cluster" state and "inbound" state) and
to introduce additional states in order to avoid races between different
CPUs in the cluster simultaneously modifying the state. The cluster-
level states are described in the "Cluster state" section.
To help distinguish the CPU states from cluster states in this
discussion, the state names are given a `CPU_` prefix for the CPU states,
and a `CLUSTER_` or `INBOUND_` prefix for the cluster states.
CPU state
---------
In this algorithm, each individual core in a multi-core processor is
referred to as a "CPU". CPUs are assumed to be single-threaded:
therefore, a CPU can only be doing one thing at a single point in time.
This means that CPUs fit the basic model closely.
The algorithm defines the following states for each CPU in the system:
- CPU_DOWN
- CPU_COMING_UP
- CPU_UP
- CPU_GOING_DOWN
::
cluster setup and
CPU setup complete policy decision
+-----------> CPU_UP ------------+
| v
CPU_COMING_UP CPU_GOING_DOWN
^ |
+----------- CPU_DOWN <----------+
policy decision CPU teardown complete
or hardware event
The definitions of the four states correspond closely to the states of
the basic model.
Transitions between states occur as follows.
A trigger event (spontaneous) means that the CPU can transition to the
next state as a result of making local progress only, with no
requirement for any external event to happen.
CPU_DOWN:
A CPU reaches the CPU_DOWN state when it is ready for
power-down. On reaching this state, the CPU will typically
power itself down or suspend itself, via a WFI instruction or a
firmware call.
Next state:
CPU_COMING_UP
Conditions:
none
Trigger events:
a) an explicit hardware power-up operation, resulting
from a policy decision on another CPU;
b) a hardware event, such as an interrupt.
CPU_COMING_UP:
A CPU cannot start participating in hardware coherency until the
cluster is set up and coherent. If the cluster is not ready,
then the CPU will wait in the CPU_COMING_UP state until the
cluster has been set up.
Next state:
CPU_UP
Conditions:
The CPU's parent cluster must be in CLUSTER_UP.
Trigger events:
Transition of the parent cluster to CLUSTER_UP.
Refer to the "Cluster state" section for a description of the
CLUSTER_UP state.
CPU_UP:
When a CPU reaches the CPU_UP state, it is safe for the CPU to
start participating in local coherency.
This is done by jumping to the kernel's CPU resume code.
Note that the definition of this state is slightly different
from the basic model definition: CPU_UP does not mean that the
CPU is coherent yet, but it does mean that it is safe to resume
the kernel. The kernel handles the rest of the resume
procedure, so the remaining steps are not visible as part of the
race avoidance algorithm.
The CPU remains in this state until an explicit policy decision
is made to shut down or suspend the CPU.
Next state:
CPU_GOING_DOWN
Conditions:
none
Trigger events:
explicit policy decision
CPU_GOING_DOWN:
While in this state, the CPU exits coherency, including any
operations required to achieve this (such as cleaning data
caches).
Next state:
CPU_DOWN
Conditions:
local CPU teardown complete
Trigger events:
(spontaneous)
Cluster state
-------------
A cluster is a group of connected CPUs with some common resources.
Because a cluster contains multiple CPUs, it can be doing multiple
things at the same time. This has some implications. In particular, a
CPU can start up while another CPU is tearing the cluster down.
In this discussion, the "outbound side" is the view of the cluster state
as seen by a CPU tearing the cluster down. The "inbound side" is the
view of the cluster state as seen by a CPU setting the CPU up.
In order to enable safe coordination in such situations, it is important
that a CPU which is setting up the cluster can advertise its state
independently of the CPU which is tearing down the cluster. For this
reason, the cluster state is split into two parts:
"cluster" state: The global state of the cluster; or the state
on the outbound side:
- CLUSTER_DOWN
- CLUSTER_UP
- CLUSTER_GOING_DOWN
"inbound" state: The state of the cluster on the inbound side.
- INBOUND_NOT_COMING_UP
- INBOUND_COMING_UP
The different pairings of these states results in six possible
states for the cluster as a whole::
CLUSTER_UP
+==========> INBOUND_NOT_COMING_UP -------------+
# |
|
CLUSTER_UP <----+ |
INBOUND_COMING_UP | v
^ CLUSTER_GOING_DOWN CLUSTER_GOING_DOWN
# INBOUND_COMING_UP <=== INBOUND_NOT_COMING_UP
CLUSTER_DOWN | |
INBOUND_COMING_UP <----+ |
|
^ |
+=========== CLUSTER_DOWN <------------+
INBOUND_NOT_COMING_UP
Transitions -----> can only be made by the outbound CPU, and
only involve changes to the "cluster" state.
Transitions ===##> can only be made by the inbound CPU, and only
involve changes to the "inbound" state, except where there is no
further transition possible on the outbound side (i.e., the
outbound CPU has put the cluster into the CLUSTER_DOWN state).
The race avoidance algorithm does not provide a way to determine
which exact CPUs within the cluster play these roles. This must
be decided in advance by some other means. Refer to the section
"Last man and first man selection" for more explanation.
CLUSTER_DOWN/INBOUND_NOT_COMING_UP is the only state where the
cluster can actually be powered down.
The parallelism of the inbound and outbound CPUs is observed by
the existence of two different paths from CLUSTER_GOING_DOWN/
INBOUND_NOT_COMING_UP (corresponding to GOING_DOWN in the basic
model) to CLUSTER_DOWN/INBOUND_COMING_UP (corresponding to
COMING_UP in the basic model). The second path avoids cluster
teardown completely.
CLUSTER_UP/INBOUND_COMING_UP is equivalent to UP in the basic
model. The final transition to CLUSTER_UP/INBOUND_NOT_COMING_UP
is trivial and merely resets the state machine ready for the
next cycle.
Details of the allowable transitions follow.
The next state in each case is notated
<cluster state>/<inbound state> (<transitioner>)
where the <transitioner> is the side on which the transition
can occur; either the inbound or the outbound side.
CLUSTER_DOWN/INBOUND_NOT_COMING_UP:
Next state:
CLUSTER_DOWN/INBOUND_COMING_UP (inbound)
Conditions:
none
Trigger events:
a) an explicit hardware power-up operation, resulting
from a policy decision on another CPU;
b) a hardware event, such as an interrupt.
CLUSTER_DOWN/INBOUND_COMING_UP:
In this state, an inbound CPU sets up the cluster, including
enabling of hardware coherency at the cluster level and any
other operations (such as cache invalidation) which are required
in order to achieve this.
The purpose of this state is to do sufficient cluster-level
setup to enable other CPUs in the cluster to enter coherency
safely.
Next state:
CLUSTER_UP/INBOUND_COMING_UP (inbound)
Conditions:
cluster-level setup and hardware coherency complete
Trigger events:
(spontaneous)
CLUSTER_UP/INBOUND_COMING_UP:
Cluster-level setup is complete and hardware coherency is
enabled for the cluster. Other CPUs in the cluster can safely
enter coherency.
This is a transient state, leading immediately to
CLUSTER_UP/INBOUND_NOT_COMING_UP. All other CPUs on the cluster
should consider treat these two states as equivalent.
Next state:
CLUSTER_UP/INBOUND_NOT_COMING_UP (inbound)
Conditions:
none
Trigger events:
(spontaneous)
CLUSTER_UP/INBOUND_NOT_COMING_UP:
Cluster-level setup is complete and hardware coherency is
enabled for the cluster. Other CPUs in the cluster can safely
enter coherency.
The cluster will remain in this state until a policy decision is
made to power the cluster down.
Next state:
CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP (outbound)
Conditions:
none
Trigger events:
policy decision to power down the cluster
CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP:
An outbound CPU is tearing the cluster down. The selected CPU
must wait in this state until all CPUs in the cluster are in the
CPU_DOWN state.
When all CPUs are in the CPU_DOWN state, the cluster can be torn
down, for example by cleaning data caches and exiting
cluster-level coherency.
To avoid wasteful unnecessary teardown operations, the outbound
should check the inbound cluster state for asynchronous
transitions to INBOUND_COMING_UP. Alternatively, individual
CPUs can be checked for entry into CPU_COMING_UP or CPU_UP.
Next states:
CLUSTER_DOWN/INBOUND_NOT_COMING_UP (outbound)
Conditions:
cluster torn down and ready to power off
Trigger events:
(spontaneous)
CLUSTER_GOING_DOWN/INBOUND_COMING_UP (inbound)
Conditions:
none
Trigger events:
a) an explicit hardware power-up operation,
resulting from a policy decision on another
CPU;
b) a hardware event, such as an interrupt.
CLUSTER_GOING_DOWN/INBOUND_COMING_UP:
The cluster is (or was) being torn down, but another CPU has
come online in the meantime and is trying to set up the cluster
again.
If the outbound CPU observes this state, it has two choices:
a) back out of teardown, restoring the cluster to the
CLUSTER_UP state;
b) finish tearing the cluster down and put the cluster
in the CLUSTER_DOWN state; the inbound CPU will
set up the cluster again from there.
Choice (a) permits the removal of some latency by avoiding
unnecessary teardown and setup operations in situations where
the cluster is not really going to be powered down.
Next states:
CLUSTER_UP/INBOUND_COMING_UP (outbound)
Conditions:
cluster-level setup and hardware
coherency complete
Trigger events:
(spontaneous)
CLUSTER_DOWN/INBOUND_COMING_UP (outbound)
Conditions:
cluster torn down and ready to power off
Trigger events:
(spontaneous)
Last man and First man selection
--------------------------------
The CPU which performs cluster tear-down operations on the outbound side
is commonly referred to as the "last man".
The CPU which performs cluster setup on the inbound side is commonly
referred to as the "first man".
The race avoidance algorithm documented above does not provide a
mechanism to choose which CPUs should play these roles.
Last man:
When shutting down the cluster, all the CPUs involved are initially
executing Linux and hence coherent. Therefore, ordinary spinlocks can
be used to select a last man safely, before the CPUs become
non-coherent.
First man:
Because CPUs may power up asynchronously in response to external wake-up
events, a dynamic mechanism is needed to make sure that only one CPU
attempts to play the first man role and do the cluster-level
initialisation: any other CPUs must wait for this to complete before
proceeding.
Cluster-level initialisation may involve actions such as configuring
coherency controls in the bus fabric.
The current implementation in mcpm_head.S uses a separate mutual exclusion
mechanism to do this arbitration. This mechanism is documented in
detail in vlocks.txt.
Features and Limitations
------------------------
Implementation:
The current ARM-based implementation is split between
arch/arm/common/mcpm_head.S (low-level inbound CPU operations) and
arch/arm/common/mcpm_entry.c (everything else):
__mcpm_cpu_going_down() signals the transition of a CPU to the
CPU_GOING_DOWN state.
__mcpm_cpu_down() signals the transition of a CPU to the CPU_DOWN
state.
A CPU transitions to CPU_COMING_UP and then to CPU_UP via the
low-level power-up code in mcpm_head.S. This could
involve CPU-specific setup code, but in the current
implementation it does not.
__mcpm_outbound_enter_critical() and __mcpm_outbound_leave_critical()
handle transitions from CLUSTER_UP to CLUSTER_GOING_DOWN
and from there to CLUSTER_DOWN or back to CLUSTER_UP (in
the case of an aborted cluster power-down).
These functions are more complex than the __mcpm_cpu_*()
functions due to the extra inter-CPU coordination which
is needed for safe transitions at the cluster level.
A cluster transitions from CLUSTER_DOWN back to CLUSTER_UP via
the low-level power-up code in mcpm_head.S. This
typically involves platform-specific setup code,
provided by the platform-specific power_up_setup
function registered via mcpm_sync_init.
Deep topologies:
As currently described and implemented, the algorithm does not
support CPU topologies involving more than two levels (i.e.,
clusters of clusters are not supported). The algorithm could be
extended by replicating the cluster-level states for the
additional topological levels, and modifying the transition
rules for the intermediate (non-outermost) cluster levels.
Colophon
--------
Originally created and documented by Dave Martin for Linaro Limited, in
collaboration with Nicolas Pitre and Achin Gupta.
Copyright (C) 2012-2013 Linaro Limited
Distributed under the terms of Version 2 of the GNU General Public
License, as defined in linux/COPYING.
linux-7.2.3/Documentation/arch/arm/features.rst
+3
View File
@@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: features arm
linux-7.2.3/Documentation/arch/arm/firmware.rst
+72
View File
@@ -0,0 +1,72 @@
==========================================================================
Interface for registering and calling firmware-specific operations for ARM
==========================================================================
Written by Tomasz Figa <t.figa@samsung.com>
Some boards are running with secure firmware running in TrustZone secure
world, which changes the way some things have to be initialized. This makes
a need to provide an interface for such platforms to specify available firmware
operations and call them when needed.
Firmware operations can be specified by filling in a struct firmware_ops
with appropriate callbacks and then registering it with register_firmware_ops()
function::
void register_firmware_ops(const struct firmware_ops *ops)
The ops pointer must be non-NULL. More information about struct firmware_ops
and its members can be found in arch/arm/include/asm/firmware.h header.
There is a default, empty set of operations provided, so there is no need to
set anything if platform does not require firmware operations.
To call a firmware operation, a helper macro is provided::
#define call_firmware_op(op, ...) \
((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
the macro checks if the operation is provided and calls it or otherwise returns
-ENOSYS to signal that given operation is not available (for example, to allow
fallback to legacy operation).
Example of registering firmware operations::
/* board file */
static int platformX_do_idle(void)
{
/* tell platformX firmware to enter idle */
return 0;
}
static int platformX_cpu_boot(int i)
{
/* tell platformX firmware to boot CPU i */
return 0;
}
static const struct firmware_ops platformX_firmware_ops = {
.do_idle = exynos_do_idle,
.cpu_boot = exynos_cpu_boot,
/* other operations not available on platformX */
};
/* init_early callback of machine descriptor */
static void __init board_init_early(void)
{
register_firmware_ops(&platformX_firmware_ops);
}
Example of using a firmware operation::
/* some platform code, e.g. SMP initialization */
__raw_writel(__pa_symbol(exynos4_secondary_startup),
CPU1_BOOT_REG);
/* Call Exynos specific smc call */
if (call_firmware_op(cpu_boot, cpu) == -ENOSYS)
cpu_boot_legacy(...); /* Try legacy way */
gic_raise_softirq(cpumask_of(cpu), 1);
linux-7.2.3/Documentation/arch/arm/google/chromebook-boot-flow.rst
+69
View File
@@ -0,0 +1,69 @@
.. SPDX-License-Identifier: GPL-2.0
======================================
Chromebook Boot Flow
======================================
Most recent Chromebooks that use device tree are using the opensource
depthcharge_ bootloader. Depthcharge_ expects the OS to be packaged as a `FIT
Image`_ which contains an OS image as well as a collection of device trees. It
is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and
provide it to the OS.
The scheme that depthcharge_ uses to pick the device tree takes into account
three variables:
- Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
- Board revision number, determined at runtime (perhaps by reading GPIO
strappings, perhaps via some other method). This is $(REV) below.
- SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
For recent Chromebooks, depthcharge_ creates a match list that looks like this:
- google,$(BOARD)-rev$(REV)-sku$(SKU)
- google,$(BOARD)-rev$(REV)
- google,$(BOARD)-sku$(SKU)
- google,$(BOARD)
Note that some older Chromebooks use a slightly different list that may
not include SKU matching or may prioritize SKU/rev differently.
Note that for some boards there may be extra board-specific logic to inject
extra compatibles into the list, but this is uncommon.
Depthcharge_ will look through all device trees in the `FIT Image`_ trying to
find one that matches the most specific compatible. It will then look
through all device trees in the `FIT Image`_ trying to find the one that
matches the *second most* specific compatible, etc.
When searching for a device tree, depthcharge_ doesn't care where the
compatible string falls within a device tree's root compatible string array.
As an example, if we're on board "lazor", rev 4, SKU 0 and we have two device
trees:
- "google,lazor-rev5-sku0", "google,lazor-rev4-sku0", "qcom,sc7180"
- "google,lazor", "qcom,sc7180"
Then depthcharge_ will pick the first device tree even though
"google,lazor-rev4-sku0" was the second compatible listed in that device tree.
This is because it is a more specific compatible than "google,lazor".
It should be noted that depthcharge_ does not have any smarts to try to
match board or SKU revisions that are "close by". That is to say that
if depthcharge_ knows it's on "rev4" of a board but there is no "rev4"
device tree then depthcharge_ *won't* look for a "rev3" device tree.
In general when any significant changes are made to a board the board
revision number is increased even if none of those changes need to
be reflected in the device tree. Thus it's fairly common to see device
trees with multiple revisions.
It should be noted that, taking into account the above system that
depthcharge_ has, the most flexibility is achieved if the device tree
supporting the newest revision(s) of a board omits the "-rev{REV}"
compatible strings. When this is done then if you get a new board
revision and try to run old software on it then we'll at pick the
newest device tree we know about.
.. _depthcharge: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/depthcharge/
.. _`FIT Image`: https://doc.coreboot.org/lib/payloads/fit.html
linux-7.2.3/Documentation/arch/arm/index.rst
+79
View File
@@ -0,0 +1,79 @@
.. SPDX-License-Identifier: GPL-2.0
================
ARM Architecture
================
.. toctree::
:maxdepth: 1
arm
booting
cluster-pm-race-avoidance
firmware
interrupts
kernel_mode_neon
kernel_user_helpers
memory
mem_alignment
tcm
setup
swp_emulation
uefi
vlocks
porting
features
SoC-specific documents
======================
.. toctree::
:maxdepth: 1
google/chromebook-boot-flow
ixp4xx
marvell
microchip
netwinder
nwfpe/index
keystone/overview
keystone/knav-qmss
omap/index
pxa/mfp
sa1100/index
stm32/stm32f746-overview
stm32/overview
stm32/stm32h743-overview
stm32/stm32h750-overview
stm32/stm32f769-overview
stm32/stm32f429-overview
stm32/stm32mp13-overview
stm32/stm32mp151-overview
stm32/stm32mp157-overview
stm32/stm32-dma-mdma-chaining
sunxi
samsung/index
sunxi/clocks
spear/overview
sti/stih407-overview
sti/stih418-overview
sti/overview
vfp/release-notes
zte/index
linux-7.2.3/Documentation/arch/arm/interrupts.rst
+169
View File
@@ -0,0 +1,169 @@
==========
Interrupts
==========
2.5.2-rmk5:
This is the first kernel that contains a major shake up of some of the
major architecture-specific subsystems.
Firstly, it contains some pretty major changes to the way we handle the
MMU TLB. Each MMU TLB variant is now handled completely separately -
we have TLB v3, TLB v4 (without write buffer), TLB v4 (with write buffer),
and finally TLB v4 (with write buffer, with I TLB invalidate entry).
There is more assembly code inside each of these functions, mainly to
allow more flexible TLB handling for the future.
Secondly, the IRQ subsystem.
The 2.5 kernels will be having major changes to the way IRQs are handled.
Unfortunately, this means that machine types that touch the irq_desc[]
array (basically all machine types) will break, and this means every
machine type that we currently have.
Lets take an example. On the Assabet with Neponset, we have::
GPIO25 IRR:2
SA1100 ------------> Neponset -----------> SA1111
IIR:1
-----------> USAR
IIR:0
-----------> SMC9196
The way stuff currently works, all SA1111 interrupts are mutually
exclusive of each other - if you're processing one interrupt from the
SA1111 and another comes in, you have to wait for that interrupt to
finish processing before you can service the new interrupt. Eg, an
IDE PIO-based interrupt on the SA1111 excludes all other SA1111 and
SMC9196 interrupts until it has finished transferring its multi-sector
data, which can be a long time. Note also that since we loop in the
SA1111 IRQ handler, SA1111 IRQs can hold off SMC9196 IRQs indefinitely.
The new approach brings several new ideas...
We introduce the concept of a "parent" and a "child". For example,
to the Neponset handler, the "parent" is GPIO25, and the "children"d
are SA1111, SMC9196 and USAR.
We also bring the idea of an IRQ "chip" (mainly to reduce the size of
the irqdesc array). This doesn't have to be a real "IC"; indeed the
SA11x0 IRQs are handled by two separate "chip" structures, one for
GPIO0-10, and another for all the rest. It is just a container for
the various operations (maybe this'll change to a better name).
This structure has the following operations::
struct irqchip {
/*
* Acknowledge the IRQ.
* If this is a level-based IRQ, then it is expected to mask the IRQ
* as well.
*/
void (*ack)(unsigned int irq);
/*
* Mask the IRQ in hardware.
*/
void (*mask)(unsigned int irq);
/*
* Unmask the IRQ in hardware.
*/
void (*unmask)(unsigned int irq);
/*
* Re-run the IRQ
*/
void (*rerun)(unsigned int irq);
/*
* Set the type of the IRQ.
*/
int (*type)(unsigned int irq, unsigned int, type);
};
ack
- required. May be the same function as mask for IRQs
handled by do_level_IRQ.
mask
- required.
unmask
- required.
rerun
- optional. Not required if you're using do_level_IRQ for all
IRQs that use this 'irqchip'. Generally expected to re-trigger
the hardware IRQ if possible. If not, may call the handler
directly.
type
- optional. If you don't support changing the type of an IRQ,
it should be null so people can detect if they are unable to
set the IRQ type.
For each IRQ, we keep the following information:
- "disable" depth (number of disable_irq()s without enable_irq()s)
- flags indicating what we can do with this IRQ (valid, probe,
noautounmask) as before
- status of the IRQ (probing, enable, etc)
- chip
- per-IRQ handler
- irqaction structure list
The handler can be one of the 3 standard handlers - "level", "edge" and
"simple", or your own specific handler if you need to do something special.
The "level" handler is what we currently have - its pretty simple.
"edge" knows about the brokenness of such IRQ implementations - that you
need to leave the hardware IRQ enabled while processing it, and queueing
further IRQ events should the IRQ happen again while processing. The
"simple" handler is very basic, and does not perform any hardware
manipulation, nor state tracking. This is useful for things like the
SMC9196 and USAR above.
So, what's changed?
===================
1. Machine implementations must not write to the irqdesc array.
2. New functions to manipulate the irqdesc array. The first 4 are expected
to be useful only to machine specific code. The last is recommended to
only be used by machine specific code, but may be used in drivers if
absolutely necessary.
set_irq_chip(irq,chip)
Set the mask/unmask methods for handling this IRQ
set_irq_handler(irq,handler)
Set the handler for this IRQ (level, edge, simple)
set_irq_chained_handler(irq,handler)
Set a "chained" handler for this IRQ - automatically
enables this IRQ (eg, Neponset and SA1111 handlers).
set_irq_flags(irq,flags)
Set the valid/probe/noautoenable flags.
set_irq_type(irq,type)
Set active the IRQ edge(s)/level. This replaces the
SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge()
function. Type should be one of IRQ_TYPE_xxx defined in
<linux/irq.h>
3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
4. Direct access to SA1111 INTPOL is deprecated. Use set_irq_type instead.
5. A handler is expected to perform any necessary acknowledgement of the
parent IRQ via the correct chip specific function. For instance, if
the SA1111 is directly connected to a SA1110 GPIO, then you should
acknowledge the SA1110 IRQ each time you re-read the SA1111 IRQ status.
6. For any child which doesn't have its own IRQ enable/disable controls
(eg, SMC9196), the handler must mask or acknowledge the parent IRQ
while the child handler is called, and the child handler should be the
"simple" handler (not "edge" nor "level"). After the handler completes,
the parent IRQ should be unmasked, and the status of all children must
be re-checked for pending events. (see the Neponset IRQ handler for
details).
7. fixup_irq() is gone, as is `arch/arm/mach-*/include/mach/irq.h`
Please note that this will not solve all problems - some of them are
hardware based. Mixing level-based and edge-based IRQs on the same
parent signal (eg neponset) is one such area where a software based
solution can't provide the full answer to low IRQ latency.
linux-7.2.3/Documentation/arch/arm/ixp4xx.rst
+173
View File
@@ -0,0 +1,173 @@
===========================================================
Release Notes for Linux on Intel's IXP4xx Network Processor
===========================================================
Maintained by Deepak Saxena <dsaxena@plexity.net>
-------------------------------------------------------------------------
1. Overview
Intel's IXP4xx network processor is a highly integrated SOC that
is targeted for network applications, though it has become popular
in industrial control and other areas due to low cost and power
consumption. The IXP4xx family currently consists of several processors
that support different network offload functions such as encryption,
routing, firewalling, etc. The IXP46x family is an updated version which
supports faster speeds, new memory and flash configurations, and more
integration such as an on-chip I2C controller.
For more information on the various versions of the CPU, see:
http://developer.intel.com/design/network/products/npfamily/ixp4xx.htm
Intel also made the IXCP1100 CPU for sometime which is an IXP4xx
stripped of much of the network intelligence.
2. Linux Support
Linux currently supports the following features on the IXP4xx chips:
- Dual serial ports
- PCI interface
- Flash access (MTD/JFFS)
- I2C through GPIO on IXP42x
- GPIO for input/output/interrupts
See arch/arm/mach-ixp4xx/include/mach/platform.h for access functions.
- Timers (watchdog, OS)
The following components of the chips are not supported by Linux and
require the use of Intel's proprietary CSR software:
- USB device interface
- Network interfaces (HSS, Utopia, NPEs, etc)
- Network offload functionality
If you need to use any of the above, you need to download Intel's
software from:
http://developer.intel.com/design/network/products/npfamily/ixp425.htm
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY
SOFTWARE.
There are several websites that provide directions/pointers on using
Intel's software:
- http://sourceforge.net/projects/ixp4xx-osdg/
Open Source Developer's Guide for using uClinux and the Intel libraries
- http://gatewaymaker.sourceforge.net/
Simple one page summary of building a gateway using an IXP425 and Linux
- http://ixp425.sourceforge.net/
ATM device driver for IXP425 that relies on Intel's libraries
3. Known Issues/Limitations
3a. Limited inbound PCI window
The IXP4xx family allows for up to 256MB of memory but the PCI interface
can only expose 64MB of that memory to the PCI bus. This means that if
you are running with > 64MB, all PCI buffers outside of the accessible
range will be bounced using the routines in arch/arm/common/dmabounce.c.
3b. Limited outbound PCI window
IXP4xx provides two methods of accessing PCI memory space:
1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB).
To access PCI via this space, we simply ioremap() the BAR
into the kernel and we can use the standard read[bwl]/write[bwl]
macros. This is the preferred method due to speed but it
limits the system to just 64MB of PCI memory. This can be
problematic if using video cards and other memory-heavy devices.
2) If > 64MB of memory space is required, the IXP4xx can be
configured to use indirect registers to access PCI This allows
for up to 128MB (0x48000000 to 0x4fffffff) of memory on the bus.
The disadvantage of this is that every PCI access requires
three local register accesses plus a spinlock, but in some
cases the performance hit is acceptable. In addition, you cannot
mmap() PCI devices in this case due to the indirect nature
of the PCI window.
By default, the direct method is used for performance reasons. If
you need more PCI memory, enable the IXP4XX_INDIRECT_PCI config option.
3c. GPIO as Interrupts
Currently the code only handles level-sensitive GPIO interrupts
4. Supported platforms
ADI Engineering Coyote Gateway Reference Platform
http://www.adiengineering.com/productsCoyote.html
The ADI Coyote platform is reference design for those building
small residential/office gateways. One NPE is connected to a 10/100
interface, one to 4-port 10/100 switch, and the third to and ADSL
interface. In addition, it also supports to POTs interfaces connected
via SLICs. Note that those are not supported by Linux ATM. Finally,
the platform has two mini-PCI slots used for 802.11[bga] cards.
Finally, there is an IDE port hanging off the expansion bus.
Gateworks Avila Network Platform
http://www.gateworks.com/support/overview.php
The Avila platform is basically and IXDP425 with the 4 PCI slots
replaced with mini-PCI slots and a CF IDE interface hanging off
the expansion bus.
Intel IXDP425 Development Platform
http://www.intel.com/design/network/products/npfamily/ixdpg425.htm
This is Intel's standard reference platform for the IXDP425 and is
also known as the Richfield board. It contains 4 PCI slots, 16MB
of flash, two 10/100 ports and one ADSL port.
Intel IXDP465 Development Platform
http://www.intel.com/design/network/products/npfamily/ixdp465.htm
This is basically an IXDP425 with an IXP465 and 32M of flash instead
of just 16.
Intel IXDPG425 Development Platform
This is basically and ADI Coyote board with a NEC EHCI controller
added. One issue with this board is that the mini-PCI slots only
have the 3.3v line connected, so you can't use a PCI to mini-PCI
adapter with an E100 card. So to NFS root you need to use either
the CSR or a WiFi card and a ramdisk that BOOTPs and then does
a pivot_root to NFS.
Motorola PrPMC1100 Processor Mezanine Card
http://www.fountainsys.com
The PrPMC1100 is based on the IXCP1100 and is meant to plug into
and IXP2400/2800 system to act as the system controller. It simply
contains a CPU and 16MB of flash on the board and needs to be
plugged into a carrier board to function. Currently Linux only
supports the Motorola PrPMC carrier board for this platform.
5. TODO LIST
- Add support for Coyote IDE
- Add support for edge-based GPIO interrupts
- Add support for CF IDE on expansion bus
6. Thanks
The IXP4xx work has been funded by Intel Corp. and MontaVista Software, Inc.
The following people have contributed patches/comments/etc:
- Lennerty Buytenhek
- Lutz Jaenicke
- Justin Mayfield
- Robert E. Ranslam
[I know I've forgotten others, please email me to be added]
-------------------------------------------------------------------------
Last Update: 01/04/2005
linux-7.2.3/Documentation/arch/arm/kernel_mode_neon.rst
+126
View File
@@ -0,0 +1,126 @@
================
Kernel mode NEON
================
TL;DR summary
-------------
* Use only NEON instructions, or VFP instructions that don't rely on support
code
* Isolate your NEON code in a separate compilation unit, and compile it with
'-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
* Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your
NEON code
* Don't sleep in your NEON code, and be aware that it will be executed with
preemption disabled
Introduction
------------
It is possible to use NEON instructions (and in some cases, VFP instructions) in
code that runs in kernel mode. However, for performance reasons, the NEON/VFP
register file is not preserved and restored at every context switch or taken
exception like the normal register file is, so some manual intervention is
required. Furthermore, special care is required for code that may sleep [i.e.,
may call schedule()], as NEON or VFP instructions will be executed in a
non-preemptible section for reasons outlined below.
Lazy preserve and restore
-------------------------
The NEON/VFP register file is managed using lazy preserve (on UP systems) and
lazy restore (on both SMP and UP systems). This means that the register file is
kept 'live', and is only preserved and restored when multiple tasks are
contending for the NEON/VFP unit (or, in the SMP case, when a task migrates to
another core). Lazy restore is implemented by disabling the NEON/VFP unit after
every context switch, resulting in a trap when subsequently a NEON/VFP
instruction is issued, allowing the kernel to step in and perform the restore if
necessary.
Any use of the NEON/VFP unit in kernel mode should not interfere with this, so
it is required to do an 'eager' preserve of the NEON/VFP register file, and
enable the NEON/VFP unit explicitly so no exceptions are generated on first
subsequent use. This is handled by the function kernel_neon_begin(), which
should be called before any kernel mode NEON or VFP instructions are issued.
Likewise, the NEON/VFP unit should be disabled again after use to make sure user
mode will hit the lazy restore trap upon next use. This is handled by the
function kernel_neon_end().
Interruptions in kernel mode
----------------------------
For reasons of performance and simplicity, it was decided that there shall be no
preserve/restore mechanism for the kernel mode NEON/VFP register contents. This
implies that interruptions of a kernel mode NEON section can only be allowed if
they are guaranteed not to touch the NEON/VFP registers. For this reason, the
following rules and restrictions apply in the kernel:
* NEON/VFP code is not allowed in interrupt context;
* NEON/VFP code is not allowed to sleep;
* NEON/VFP code is executed with preemption disabled.
If latency is a concern, it is possible to put back to back calls to
kernel_neon_end() and kernel_neon_begin() in places in your code where none of
the NEON registers are live. (Additional calls to kernel_neon_begin() should be
reasonably cheap if no context switch occurred in the meantime)
VFP and support code
--------------------
Earlier versions of VFP (prior to version 3) rely on software support for things
like IEEE-754 compliant underflow handling etc. When the VFP unit needs such
software assistance, it signals the kernel by raising an undefined instruction
exception. The kernel responds by inspecting the VFP control registers and the
current instruction and arguments, and emulates the instruction in software.
Such software assistance is currently not implemented for VFP instructions
executed in kernel mode. If such a condition is encountered, the kernel will
fail and generate an OOPS.
Separating NEON code from ordinary code
---------------------------------------
The compiler is not aware of the special significance of kernel_neon_begin() and
kernel_neon_end(), i.e., that it is only allowed to issue NEON/VFP instructions
between calls to these respective functions. Furthermore, GCC may generate NEON
instructions of its own at -O3 level if -mfpu=neon is selected, and even if the
kernel is currently compiled at -O2, future changes may result in NEON/VFP
instructions appearing in unexpected places if no special care is taken.
Therefore, the recommended and only supported way of using NEON/VFP in the
kernel is by adhering to the following rules:
* isolate the NEON code in a separate compilation unit and compile it with
'-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
* issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
into the unit containing the NEON code from a compilation unit which is *not*
built with the GCC flag '-mfpu=neon' set.
As the kernel is compiled with '-msoft-float', the above will guarantee that
both NEON and VFP instructions will only ever appear in designated compilation
units at any optimization level.
NEON assembler
--------------
NEON assembler is supported with no additional caveats as long as the rules
above are followed.
NEON code generated by GCC
--------------------------
The GCC option -ftree-vectorize (implied by -O3) tries to exploit implicit
parallelism, and generates NEON code from ordinary C source code. This is fully
supported as long as the rules above are followed.
NEON intrinsics
---------------
NEON intrinsics are also supported. However, as code using NEON intrinsics
relies on the GCC header <arm_neon.h>, (which #includes <stdint.h>), you should
observe the following in addition to the rules above:
* Compile the unit containing the NEON intrinsics with '-ffreestanding' so GCC
uses its builtin version of <stdint.h> (this is a C99 header which the kernel
does not supply);
* Do not include <arm_neon.h> directly: instead, include <asm/neon-intrinsics.h>,
which tweaks some macro definitions so that system headers can be included
safely.
linux-7.2.3/Documentation/arch/arm/kernel_user_helpers.rst
+268
View File
@@ -0,0 +1,268 @@
============================
Kernel-provided User Helpers
============================
These are segment of kernel provided user code reachable from user space
at a fixed address in kernel memory. This is used to provide user space
with some operations which require kernel help because of unimplemented
native feature and/or instructions in many ARM CPUs. The idea is for this
code to be executed directly in user mode for best efficiency but which is
too intimate with the kernel counter part to be left to user libraries.
In fact this code might even differ from one CPU to another depending on
the available instruction set, or whether it is a SMP systems. In other
words, the kernel reserves the right to change this code as needed without
warning. Only the entry points and their results as documented here are
guaranteed to be stable.
This is different from (but doesn't preclude) a full blown VDSO
implementation, however a VDSO would prevent some assembly tricks with
constants that allows for efficient branching to those code segments. And
since those code segments only use a few cycles before returning to user
code, the overhead of a VDSO indirect far call would add a measurable
overhead to such minimalistic operations.
User space is expected to bypass those helpers and implement those things
inline (either in the code emitted directly by the compiler, or part of
the implementation of a library call) when optimizing for a recent enough
processor that has the necessary native support, but only if resulting
binaries are already to be incompatible with earlier ARM processors due to
usage of similar native instructions for other things. In other words
don't make binaries unable to run on earlier processors just for the sake
of not using these kernel helpers if your compiled code is not going to
use new instructions for other purpose.
New helpers may be added over time, so an older kernel may be missing some
helpers present in a newer kernel. For this reason, programs must check
the value of __kuser_helper_version (see below) before assuming that it is
safe to call any particular helper. This check should ideally be
performed only once at process startup time, and execution aborted early
if the required helpers are not provided by the kernel version that
process is running on.
kuser_helper_version
--------------------
Location: 0xffff0ffc
Reference declaration::
extern int32_t __kuser_helper_version;
Definition:
This field contains the number of helpers being implemented by the
running kernel. User space may read this to determine the availability
of a particular helper.
Usage example::
#define __kuser_helper_version (*(int32_t *)0xffff0ffc)
void check_kuser_version(void)
{
if (__kuser_helper_version < 2) {
fprintf(stderr, "can't do atomic operations, kernel too old\n");
abort();
}
}
Notes:
User space may assume that the value of this field never changes
during the lifetime of any single process. This means that this
field can be read once during the initialisation of a library or
startup phase of a program.
kuser_get_tls
-------------
Location: 0xffff0fe0
Reference prototype::
void * __kuser_get_tls(void);
Input:
lr = return address
Output:
r0 = TLS value
Clobbered registers:
none
Definition:
Get the TLS value as previously set via the __ARM_NR_set_tls syscall.
Usage example::
typedef void * (__kuser_get_tls_t)(void);
#define __kuser_get_tls (*(__kuser_get_tls_t *)0xffff0fe0)
void foo()
{
void *tls = __kuser_get_tls();
printf("TLS = %p\n", tls);
}
Notes:
- Valid only if __kuser_helper_version >= 1 (from kernel version 2.6.12).
kuser_cmpxchg
-------------
Location: 0xffff0fc0
Reference prototype::
int __kuser_cmpxchg(int32_t oldval, int32_t newval, volatile int32_t *ptr);
Input:
r0 = oldval
r1 = newval
r2 = ptr
lr = return address
Output:
r0 = success code (zero or non-zero)
C flag = set if r0 == 0, clear if r0 != 0
Clobbered registers:
r3, ip, flags
Definition:
Atomically store newval in `*ptr` only if `*ptr` is equal to oldval.
Return zero if `*ptr` was changed or non-zero if no exchange happened.
The C flag is also set if `*ptr` was changed to allow for assembly
optimization in the calling code.
Usage example::
typedef int (__kuser_cmpxchg_t)(int oldval, int newval, volatile int *ptr);
#define __kuser_cmpxchg (*(__kuser_cmpxchg_t *)0xffff0fc0)
int atomic_add(volatile int *ptr, int val)
{
int old, new;
do {
old = *ptr;
new = old + val;
} while(__kuser_cmpxchg(old, new, ptr));
return new;
}
Notes:
- This routine already includes memory barriers as needed.
- Valid only if __kuser_helper_version >= 2 (from kernel version 2.6.12).
kuser_memory_barrier
--------------------
Location: 0xffff0fa0
Reference prototype::
void __kuser_memory_barrier(void);
Input:
lr = return address
Output:
none
Clobbered registers:
none
Definition:
Apply any needed memory barrier to preserve consistency with data modified
manually and __kuser_cmpxchg usage.
Usage example::
typedef void (__kuser_dmb_t)(void);
#define __kuser_dmb (*(__kuser_dmb_t *)0xffff0fa0)
Notes:
- Valid only if __kuser_helper_version >= 3 (from kernel version 2.6.15).
kuser_cmpxchg64
---------------
Location: 0xffff0f60
Reference prototype::
int __kuser_cmpxchg64(const int64_t *oldval,
const int64_t *newval,
volatile int64_t *ptr);
Input:
r0 = pointer to oldval
r1 = pointer to newval
r2 = pointer to target value
lr = return address
Output:
r0 = success code (zero or non-zero)
C flag = set if r0 == 0, clear if r0 != 0
Clobbered registers:
r3, lr, flags
Definition:
Atomically store the 64-bit value pointed by `*newval` in `*ptr` only if `*ptr`
is equal to the 64-bit value pointed by `*oldval`. Return zero if `*ptr` was
changed or non-zero if no exchange happened.
The C flag is also set if `*ptr` was changed to allow for assembly
optimization in the calling code.
Usage example::
typedef int (__kuser_cmpxchg64_t)(const int64_t *oldval,
const int64_t *newval,
volatile int64_t *ptr);
#define __kuser_cmpxchg64 (*(__kuser_cmpxchg64_t *)0xffff0f60)
int64_t atomic_add64(volatile int64_t *ptr, int64_t val)
{
int64_t old, new;
do {
old = *ptr;
new = old + val;
} while(__kuser_cmpxchg64(&old, &new, ptr));
return new;
}
Notes:
- This routine already includes memory barriers as needed.
- Due to the length of this sequence, this spans 2 conventional kuser
"slots", therefore 0xffff0f80 is not used as a valid entry point.
- Valid only if __kuser_helper_version >= 5 (from kernel version 3.1).
linux-7.2.3/Documentation/arch/arm/keystone/knav-qmss.rst
+60
View File
@@ -0,0 +1,60 @@
======================================================================
Texas Instruments Keystone Navigator Queue Management SubSystem driver
======================================================================
Driver source code path
drivers/soc/ti/knav_qmss.c
drivers/soc/ti/knav_qmss_acc.c
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
the main hardware sub system which forms the backbone of the Keystone
multi-core Navigator. QMSS consist of queue managers, packed-data structure
processors(PDSP), linking RAM, descriptor pools and infrastructure
Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating
management of the packet queues. Packets are queued/de-queued by writing or
reading descriptor address to a particular memory mapped location. The PDSPs
perform QMSS related functions like accumulation, QoS, or event management.
Linking RAM registers are used to link the descriptors which are stored in
descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions,
queue pool management (allocation, push, pop and notify) and descriptor
pool management.
knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
allocate descriptor pools, map the descriptors, push/pop to queues etc. For
details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
DT documentation is available at
Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
Accumulator QMSS queues using PDSP firmware
============================================
The QMSS PDSP firmware support accumulator channel that can monitor a single
queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
driver that interface with the accumulator PDSP. This configures
accumulator channels defined in DTS (example in DT documentation) to monitor
1 or 32 queues per channel. More description on the firmware is available in
CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
git://git.ti.com/keystone-rtos/qmss-lld.git
k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports up to 48 accumulator
channels. This firmware is available under ti-keystone folder of
firmware.git at
git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
To use copy the firmware image to lib/firmware folder of the initramfs or
ubifs file system and provide a sym link to k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
in the file system and boot up the kernel. User would see
"firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
in the boot up log if loading of firmware to PDSP is successful.
Use of accumulated queues requires the firmware image to be present in the
file system. The driver doesn't acc queues to the supported queue range if
PDSP is not running in the SoC. The API call fails if there is a queue open
request to an acc queue and PDSP is not running. So make sure to copy firmware
to file system before using these queue types.
linux-7.2.3/Documentation/arch/arm/keystone/overview.rst
+74
View File
@@ -0,0 +1,74 @@
==========================
TI Keystone Linux Overview
==========================
Introduction
------------
Keystone range of SoCs are based on ARM Cortex-A15 MPCore Processors
and c66x DSP cores. This document describes essential information required
for users to run Linux on Keystone based EVMs from Texas Instruments.
Following SoCs & EVMs are currently supported:-
K2HK SoC and EVM
=================
a.k.a Keystone 2 Hawking/Kepler SoC
TCI6636K2H & TCI6636K2K: See documentation at
http://www.ti.com/product/tci6638k2k
http://www.ti.com/product/tci6638k2h
EVM:
http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
K2E SoC and EVM
===============
a.k.a Keystone 2 Edison SoC
K2E - 66AK2E05:
See documentation at
http://www.ti.com/product/66AK2E05/technicaldocuments
EVM:
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html
K2L SoC and EVM
===============
a.k.a Keystone 2 Lamarr SoC
K2L - TCI6630K2L:
See documentation at
http://www.ti.com/product/TCI6630K2L/technicaldocuments
EVM:
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2l-evm.html
Configuration
-------------
All of the K2 SoCs/EVMs share a common defconfig, keystone_defconfig and same
image is used to boot on individual EVMs. The platform configuration is
specified through DTS. Following are the DTS used:
K2HK EVM:
k2hk-evm.dts
K2E EVM:
k2e-evm.dts
K2L EVM:
k2l-evm.dts
The device tree documentation for the keystone machines are located at
Documentation/devicetree/bindings/arm/ti/ti,keystone.yaml
Document Author
---------------
Murali Karicheri <m-karicheri2@ti.com>
Copyright 2015 Texas Instruments
linux-7.2.3/Documentation/arch/arm/marvell.rst
+527
View File
@@ -0,0 +1,527 @@
================
ARM Marvell SoCs
================
This document lists all the ARM Marvell SoCs that are currently
supported in mainline by the Linux kernel. As the Marvell families of
SoCs are large and complex, it is hard to understand where the support
for a particular SoC is available in the Linux kernel. This document
tries to help in understanding where those SoCs are supported, and to
match them with their corresponding public datasheet, when available.
Orion family
------------
Flavors:
- 88F5082
- 88F5181 a.k.a Orion-1
- 88F5181L a.k.a Orion-VoIP
- 88F5182 a.k.a Orion-NAS
- Datasheet: https://web.archive.org/web/20210124231420/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-datasheet.pdf
- Programmer's User Guide: https://web.archive.org/web/20210124231536/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-opensource-manual.pdf
- User Manual: https://web.archive.org/web/20210124231631/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-usermanual.pdf
- Functional Errata: https://web.archive.org/web/20210704165540/https://www.digriz.org.uk/ts78xx/88F5182_Functional_Errata.pdf
- 88F5281 a.k.a Orion-2
- Datasheet: https://web.archive.org/web/20131028144728/http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
- 88F6183 a.k.a Orion-1-90
Homepage:
https://web.archive.org/web/20080607215437/http://www.marvell.com/products/media/index.jsp
Core:
Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible
Linux kernel mach directory:
arch/arm/mach-orion5x
Linux kernel plat directory:
arch/arm/plat-orion
Kirkwood family
---------------
Flavors:
- 88F6282 a.k.a Armada 300
- Product Brief : https://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
- 88F6283 a.k.a Armada 310
- Product Brief : https://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
- 88F6190
- Product Brief : https://web.archive.org/web/20130730072715/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf
- Hardware Spec : https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
- Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
- 88F6192
- Product Brief : https://web.archive.org/web/20131113121446/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf
- Hardware Spec : https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
- Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
- 88F6182
- 88F6180
- Product Brief : https://web.archive.org/web/20120616201621/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf
- Hardware Spec : https://web.archive.org/web/20130730091654/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
- Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
- 88F6280
- Product Brief : https://web.archive.org/web/20130730091058/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6280_SoC_PB-001.pdf
- 88F6281
- Product Brief : https://web.archive.org/web/20120131133709/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf
- Hardware Spec : https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
- Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
- 88F6321
- 88F6322
- 88F6323
- Product Brief : https://web.archive.org/web/20120616201639/http://www.marvell.com/embedded-processors/kirkwood/assets/88f632x_pb.pdf
Homepage:
https://web.archive.org/web/20160513194943/http://www.marvell.com/embedded-processors/kirkwood/
Core:
Feroceon 88fr131 ARMv5 compatible
Linux kernel mach directory:
arch/arm/mach-mvebu
Linux kernel plat directory:
none
Discovery family
----------------
Flavors:
- MV78100
- Product Brief : https://web.archive.org/web/20120616194711/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78100-003_WEB.pdf
- Hardware Spec : https://web.archive.org/web/20141005120451/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78100_OpenSource.pdf
- Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
- MV78200
- Product Brief : https://web.archive.org/web/20140801121623/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78200-002_WEB.pdf
- Hardware Spec : https://web.archive.org/web/20141005120458/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78200_OpenSource.pdf
- Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
- MV76100
- Product Brief : https://web.archive.org/web/20140722064429/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV76100-002_WEB.pdf
- Hardware Spec : https://web.archive.org/web/20140722064425/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV76100_OpenSource.pdf
- Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
Not supported by the Linux kernel.
Homepage:
https://web.archive.org/web/20110924171043/http://www.marvell.com/embedded-processors/discovery-innovation/
Core:
Feroceon 88fr571-vd ARMv5 compatible
Linux kernel mach directory:
arch/arm/mach-mv78xx0
Linux kernel plat directory:
arch/arm/plat-orion
EBU Armada family
-----------------
Armada 370 Flavors:
- 88F6710
- 88F6707
- 88F6W11
- Product infos: https://web.archive.org/web/20141002083258/http://www.marvell.com/embedded-processors/armada-370/
- Product Brief: https://web.archive.org/web/20121115063038/http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
- Hardware Spec: https://web.archive.org/web/20140617183747/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
- Functional Spec: https://web.archive.org/web/20140617183701/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
Core:
Sheeva ARMv7 compatible PJ4B
Armada XP Flavors:
- MV78230
- MV78260
- MV78460
NOTE:
not to be confused with the non-SMP 78xx0 SoCs
- Product infos: https://web.archive.org/web/20150101215721/http://www.marvell.com/embedded-processors/armada-xp/
- Product Brief: https://web.archive.org/web/20121021173528/http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
- Functional Spec: https://web.archive.org/web/20180829171131/http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
- Hardware Specs:
- https://web.archive.org/web/20141127013651/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
- https://web.archive.org/web/20141222000224/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
- https://web.archive.org/web/20141222000230/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
Core:
Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP
Armada 375 Flavors:
- 88F6720
- Product infos: https://web.archive.org/web/20140108032402/http://www.marvell.com/embedded-processors/armada-375/
- Product Brief: https://web.archive.org/web/20131216023516/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
Core:
ARM Cortex-A9
Armada 38x Flavors:
- 88F6810 Armada 380
- 88F6811 Armada 381
- 88F6821 Armada 382
- 88F6W21 Armada 383
- 88F6820 Armada 385
- 88F6825
- 88F6828 Armada 388
- Product infos: https://web.archive.org/web/20181006144616/http://www.marvell.com/embedded-processors/armada-38x/
- Functional Spec: https://web.archive.org/web/20200420191927/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf
- Hardware Spec: https://web.archive.org/web/20180713105318/https://www.marvell.com/docs/embedded-processors/assets/marvell-embedded-processors-armada-38x-hardware-specifications-2017-03.pdf
- Design guide: https://web.archive.org/web/20180712231737/https://www.marvell.com/docs/embedded-processors/assets/marvell-embedded-processors-armada-38x-hardware-design-guide-2017-08.pdf
Core:
ARM Cortex-A9
Armada 39x Flavors:
- 88F6920 Armada 390
- 88F6925 Armada 395
- 88F6928 Armada 398
- Product infos: https://web.archive.org/web/20181020222559/http://www.marvell.com/embedded-processors/armada-39x/
Core:
ARM Cortex-A9
Linux kernel mach directory:
arch/arm/mach-mvebu
Linux kernel plat directory:
none
EBU Armada family ARMv8
-----------------------
Armada 3710/3720 Flavors:
- 88F3710
- 88F3720
Core:
ARM Cortex A53 (ARMv8)
Homepage:
https://web.archive.org/web/20181103003602/http://www.marvell.com/embedded-processors/armada-3700/
Product Brief:
https://web.archive.org/web/20210121194810/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-product-brief-2016-01.pdf
Hardware Spec:
https://web.archive.org/web/20210202162011/http://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-hardware-specifications-2019-09.pdf
Device tree files:
arch/arm64/boot/dts/marvell/armada-37*
Armada 7K Flavors:
- 88F6040 (AP806 Quad 600 MHz + one CP110)
- 88F7020 (AP806 Dual + one CP110)
- 88F7040 (AP806 Quad + one CP110)
Core: ARM Cortex A72
Homepage:
https://web.archive.org/web/20181020222606/http://www.marvell.com/embedded-processors/armada-70xx/
Product Brief:
- https://web.archive.org/web/20161010105541/http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf
- https://web.archive.org/web/20160928154533/http://www.marvell.com/embedded-processors/assets/Armada7040PB-Jan2016.pdf
Device tree files:
arch/arm64/boot/dts/marvell/armada-70*
Armada 8K Flavors:
- 88F8020 (AP806 Dual + two CP110)
- 88F8040 (AP806 Quad + two CP110)
Core:
ARM Cortex A72
Homepage:
https://web.archive.org/web/20181022004830/http://www.marvell.com/embedded-processors/armada-80xx/
Product Brief:
- https://web.archive.org/web/20210124233728/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-8020-product-brief-2017-12.pdf
- https://web.archive.org/web/20161010105532/http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf
Device tree files:
arch/arm64/boot/dts/marvell/armada-80*
Octeon TX2 CN913x Flavors:
- CN9130 (AP807 Quad + one internal CP115)
- CN9131 (AP807 Quad + one internal CP115 + one external CP115 / 88F8215)
- CN9132 (AP807 Quad + one internal CP115 + two external CP115 / 88F8215)
Core:
ARM Cortex A72
Homepage:
https://web.archive.org/web/20200803150818/https://www.marvell.com/products/infrastructure-processors/multi-core-processors/octeon-tx2/octeon-tx2-cn9130.html
Product Brief:
https://web.archive.org/web/20200803150818/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-infrastructure-processors-octeon-tx2-cn913x-product-brief-2020-02.pdf
Device tree files:
arch/arm64/boot/dts/marvell/cn913*
Avanta family
-------------
Flavors:
- 88F6500
- 88F6510
- 88F6530P
- 88F6550
- 88F6560
- 88F6601
Homepage:
https://web.archive.org/web/20181005145041/http://www.marvell.com/broadband/
Product Brief:
https://web.archive.org/web/20180829171057/http://www.marvell.com/broadband/assets/Marvell_Avanta_88F6510_305_060-001_product_brief.pdf
No public datasheet available.
Core:
ARMv5 compatible
Linux kernel mach directory:
no code in mainline yet, planned for the future
Linux kernel plat directory:
no code in mainline yet, planned for the future
Storage family
--------------
Armada SP:
- 88RC1580
Product infos:
https://web.archive.org/web/20191129073953/http://www.marvell.com/storage/armada-sp/
Core:
Sheeva ARMv7 compatible Quad-core PJ4C
(not supported in upstream Linux kernel)
Dove family (application processor)
-----------------------------------
Flavors:
- 88AP510 a.k.a Armada 510
Product Brief:
https://web.archive.org/web/20111102020643/http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf
Hardware Spec:
https://web.archive.org/web/20160428160231/http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Hardware-Spec.pdf
Functional Spec:
https://web.archive.org/web/20120130172443/http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
Homepage:
https://web.archive.org/web/20160822232651/http://www.marvell.com/application-processors/armada-500/
Core:
ARMv7 compatible
Directory:
- arch/arm/mach-mvebu (DT enabled platforms)
- arch/arm/mach-dove (non-DT enabled platforms)
PXA 2xx/3xx/93x/95x family
--------------------------
Flavors:
- PXA21x, PXA25x, PXA26x
- Application processor only
- Core: ARMv5 XScale1 core
- PXA270, PXA271, PXA272
- Product Brief : https://web.archive.org/web/20150927135510/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
- Design guide : https://web.archive.org/web/20120111181937/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
- Developers manual : https://web.archive.org/web/20150927164805/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_dev_man.pdf
- Specification : https://web.archive.org/web/20140211221535/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
- Specification update : https://web.archive.org/web/20120111104906/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
- Application processor only
- Core: ARMv5 XScale2 core
- PXA300, PXA310, PXA320
- PXA 300 Product Brief : https://web.archive.org/web/20120111121203/http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
- PXA 310 Product Brief : https://web.archive.org/web/20120111104515/http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
- PXA 320 Product Brief : https://web.archive.org/web/20121021182826/http://www.marvell.com/application-processors/pxa-family/assets/PXA320_PB_R4.pdf
- Design guide : https://web.archive.org/web/20130727144625/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Design_Guide.pdf
- Developers manual : https://web.archive.org/web/20130727144605/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip
- Specifications : https://web.archive.org/web/20130727144559/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_EMTS.pdf
- Specification Update : https://web.archive.org/web/20150927183411/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
- Reference Manual : https://web.archive.org/web/20120111103844/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf
- Application processor only
- Core: ARMv5 XScale3 core
- PXA930, PXA935
- Application processor with Communication processor
- Core: ARMv5 XScale3 core
- PXA955
- Application processor with Communication processor
- Core: ARMv7 compatible Sheeva PJ4 core
Comments:
* This line of SoCs originates from the XScale family developed by
Intel and acquired by Marvell in ~2006. The PXA21x, PXA25x,
PXA26x, PXA27x, PXA3xx and PXA93x were developed by Intel, while
the later PXA95x were developed by Marvell.
* Due to their XScale origin, these SoCs have virtually nothing in
common with the other (Kirkwood, Dove, etc.) families of Marvell
SoCs, except with the MMP/MMP2 family of SoCs.
Linux kernel mach directory:
arch/arm/mach-pxa
MMP/MMP2/MMP3 family (communication processor)
----------------------------------------------
Flavors:
- PXA168, a.k.a Armada 168
- Homepage : https://web.archive.org/web/20110926014256/http://www.marvell.com/application-processors/armada-100/armada-168.jsp
- Product brief : https://web.archive.org/web/20111102030100/http://www.marvell.com/application-processors/armada-100/assets/pxa_168_pb.pdf
- Hardware manual : https://web.archive.org/web/20160428165359/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_datasheet.pdf
- Software manual : https://web.archive.org/web/20160428154454/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_software_manual.pdf
- Specification update : https://web.archive.org/web/20150927160338/http://www.marvell.com/application-processors/armada-100/assets/ARMADA16x_Spec_update.pdf
- Boot ROM manual : https://web.archive.org/web/20130727205559/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
- App node package : https://web.archive.org/web/20141005090706/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf
- Application processor only
- Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
- PXA910/PXA920
- Homepage : https://web.archive.org/web/20150928121236/http://www.marvell.com/communication-processors/pxa910/
- Product Brief : https://archive.org/download/marvell-pxa910-pb/Marvell_PXA910_Platform-001_PB.pdf
- Application processor with Communication processor
- Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
- PXA688, a.k.a. MMP2, a.k.a Armada 610 (OLPC XO-1.75)
- Product Brief : https://web.archive.org/web/20111102023255/http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf
- Application processor only
- Core: ARMv7 compatible Sheeva PJ4 88sv581x core
- PXA2128, a.k.a. MMP3, a.k.a Armada 620 (OLPC XO-4)
- Product Brief : https://web.archive.org/web/20120824055155/http://www.marvell.com/application-processors/armada/pxa2128/assets/Marvell-ARMADA-PXA2128-SoC-PB.pdf
- Application processor only
- Core: Dual-core ARMv7 compatible Sheeva PJ4C core
- PXA960/PXA968/PXA978 (Linux support not upstream)
- Application processor with Communication Processor
- Core: ARMv7 compatible Sheeva PJ4 core
- PXA986/PXA988 (Linux support not upstream)
- Application processor with Communication Processor
- Core: Dual-core ARMv7 compatible Sheeva PJ4B-MP core
- PXA1088/PXA1920 (Linux support not upstream)
- Application processor with Communication Processor
- Core: quad-core ARMv7 Cortex-A7
- PXA1908/PXA1928/PXA1936
- Application processor with Communication Processor
- Core: multi-core ARMv8 Cortex-A53
Comments:
* This line of SoCs originates from the XScale family developed by
Intel and acquired by Marvell in ~2006. All the processors of
this MMP/MMP2 family were developed by Marvell.
* Due to their XScale origin, these SoCs have virtually nothing in
common with the other (Kirkwood, Dove, etc.) families of Marvell
SoCs, except with the PXA family of SoCs listed above.
Linux kernel mach directory:
arch/arm/mach-mmp
Berlin family (Multimedia Solutions)
-------------------------------------
- Flavors:
- 88DE3010, Armada 1000 (no Linux support)
- Core: Marvell PJ1 (ARMv5TE), Dual-core
- Product Brief: https://web.archive.org/web/20131103162620/http://www.marvell.com/digital-entertainment/assets/armada_1000_pb.pdf
- 88DE3005, Armada 1500 Mini
- Design name: BG2CD
- Core: ARM Cortex-A9, PL310 L2CC
- 88DE3006, Armada 1500 Mini Plus
- Design name: BG2CDP
- Core: Dual Core ARM Cortex-A7
- 88DE3100, Armada 1500
- Design name: BG2
- Core: Marvell PJ4B-MP (ARMv7), Tauros3 L2CC
- 88DE3114, Armada 1500 Pro
- Design name: BG2Q
- Core: Quad Core ARM Cortex-A9, PL310 L2CC
- 88DE3214, Armada 1500 Pro 4K
- Design name: BG3
- Core: ARM Cortex-A15, CA15 integrated L2CC
- 88DE3218, ARMADA 1500 Ultra
- Core: ARM Cortex-A53
Homepage: https://www.synaptics.com/products/multimedia-solutions
Directory: arch/arm/mach-berlin
Comments:
* This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...).
* The Berlin family was acquired by Synaptics from Marvell in 2017.
CPU Cores
---------
The XScale cores were designed by Intel, and shipped by Marvell in the older
PXA processors. Feroceon is a Marvell designed core that developed in-house,
and that evolved into Sheeva. The XScale and Feroceon cores were phased out
over time and replaced with Sheeva cores in later products, which subsequently
got replaced with licensed ARM Cortex-A cores.
XScale 1
CPUID 0x69052xxx
ARMv5, iWMMXt
XScale 2
CPUID 0x69054xxx
ARMv5, iWMMXt
XScale 3
CPUID 0x69056xxx or 0x69056xxx
ARMv5, iWMMXt
Feroceon-1850 88fr331 "Mohawk"
CPUID 0x5615331x or 0x41xx926x
ARMv5TE, single issue
Feroceon-2850 88fr531-vd "Jolteon"
CPUID 0x5605531x or 0x41xx926x
ARMv5TE, VFP, dual-issue
Feroceon 88fr571-vd "Jolteon"
CPUID 0x5615571x
ARMv5TE, VFP, dual-issue
Feroceon 88fr131 "Mohawk-D"
CPUID 0x5625131x
ARMv5TE, single-issue in-order
Sheeva PJ1 88sv331 "Mohawk"
CPUID 0x561584xx
ARMv5, single-issue iWMMXt v2
Sheeva PJ4 88sv581x "Flareon"
CPUID 0x560f581x
ARMv7, idivt, optional iWMMXt v2
Sheeva PJ4B 88sv581x
CPUID 0x561f581x
ARMv7, idivt, optional iWMMXt v2
Sheeva PJ4B-MP / PJ4C
CPUID 0x562f584x
ARMv7, idivt/idiva, LPAE, optional iWMMXt v2 and/or NEON
Long-term plans
---------------
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ into the
mach-mvebu/ to support all SoCs from the Marvell EBU (Engineering
Business Unit) in a single mach-<foo> directory. The plat-orion/
would therefore disappear.
Credits
-------
- Maen Suleiman <maen@marvell.com>
- Lior Amsalem <alior@marvell.com>
- Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- Andrew Lunn <andrew@lunn.ch>
- Nicolas Pitre <nico@fluxnic.net>
- Eric Miao <eric.y.miao@gmail.com>
linux-7.2.3/Documentation/arch/arm/mem_alignment.rst
+63
View File
@@ -0,0 +1,63 @@
================
Memory alignment
================
Too many problems popped up because of unnoticed misaligned memory access in
kernel code lately. Therefore the alignment fixup is now unconditionally
configured in for SA11x0 based targets. According to Alan Cox, this is a
bad idea to configure it out, but Russell King has some good reasons for
doing so on some f***ed up ARM architectures like the EBSA110. However
this is not the case on many design I'm aware of, like all SA11x0 based
ones.
Of course this is a bad idea to rely on the alignment trap to perform
unaligned memory access in general. If those access are predictable, you
are better to use the macros provided by include/linux/unaligned.h. The
alignment trap can fixup misaligned access for the exception cases, but at
a high performance cost. It better be rare.
Now for user space applications, it is possible to configure the alignment
trap to SIGBUS any code performing unaligned access (good for debugging bad
code), or even fixup the access by software like for kernel code. The later
mode isn't recommended for performance reasons (just think about the
floating point emulation that works about the same way). Fix your code
instead!
Please note that randomly changing the behaviour without good thought is
real bad - it changes the behaviour of all unaligned instructions in user
space, and might cause programs to fail unexpectedly.
To change the alignment trap behavior, simply echo a number into
/proc/cpu/alignment. The number is made up from various bits:
=== ========================================================
bit behavior when set
=== ========================================================
0 A user process performing an unaligned memory access
will cause the kernel to print a message indicating
process name, pid, pc, instruction, address, and the
fault code.
1 The kernel will attempt to fix up the user process
performing the unaligned access. This is of course
slow (think about the floating point emulator) and
not recommended for production use.
2 The kernel will send a SIGBUS signal to the user process
performing the unaligned access.
=== ========================================================
Note that not all combinations are supported - only values 0 through 5.
(6 and 7 don't make sense).
For example, the following will turn on the warnings, but without
fixing up or sending SIGBUS signals::
echo 1 > /proc/cpu/alignment
You can also read the content of the same file to get statistical
information on unaligned access occurrences plus the current mode of
operation for user space code.
Nicolas Pitre, Mar 13, 2001. Modified Russell King, Nov 30, 2001.
linux-7.2.3/Documentation/arch/arm/memory.rst
+103
View File
@@ -0,0 +1,103 @@
=================================
Kernel Memory Layout on ARM Linux
=================================
Russell King <rmk@arm.linux.org.uk>
November 17, 2005 (2.6.15)
This document describes the virtual memory layout which the Linux
kernel uses for ARM processors. It indicates which regions are
free for platforms to use, and which are used by generic code.
The ARM CPU is capable of addressing a maximum of 4GB virtual memory
space, and this must be shared between user space processes, the
kernel, and hardware devices.
As the ARM architecture matures, it becomes necessary to reserve
certain regions of VM space for use for new facilities; therefore
this document may reserve more VM space over time.
=============== =============== ===============================================
Start End Use
=============== =============== ===============================================
ffff8000 ffffffff copy_user_page / clear_user_page use.
For SA11xx and Xscale, this is used to
setup a minicache mapping.
ffff4000 ffffffff cache aliasing on ARMv6 and later CPUs.
ffff1000 ffff7fff Reserved.
Platforms must not use this address range.
ffff0000 ffff0fff CPU vector page.
The CPU vectors are mapped here if the
CPU supports vector relocation (control
register V bit.)
fffe0000 fffeffff XScale cache flush area. This is used
in proc-xscale.S to flush the whole data
cache. (XScale does not have TCM.)
fffe8000 fffeffff DTCM mapping area for platforms with
DTCM mounted inside the CPU.
fffe0000 fffe7fff ITCM mapping area for platforms with
ITCM mounted inside the CPU.
ffc80000 ffefffff Fixmap mapping region. Addresses provided
by fix_to_virt() will be located here.
ffc00000 ffc7ffff Guard region
ff800000 ffbfffff Permanent, fixed read-only mapping of the
firmware provided DT blob
fee00000 feffffff Mapping of PCI I/O space. This is a static
mapping within the vmalloc space.
VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space.
Memory returned by vmalloc/ioremap will
be dynamically placed in this region.
Machine specific static mappings are also
located here through iotable_init().
VMALLOC_START is based upon the value
of the high_memory variable, and VMALLOC_END
is equal to 0xff800000.
PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
This maps the platforms RAM, and typically
maps all platform RAM in a 1:1 relationship.
PKMAP_BASE PAGE_OFFSET-1 Permanent kernel mappings
One way of mapping HIGHMEM pages into kernel
space.
MODULES_VADDR MODULES_END-1 Kernel module space
Kernel modules inserted via insmod are
placed here using dynamic mappings.
TASK_SIZE MODULES_VADDR-1 KASAn shadow memory when KASan is in use.
The range from MODULES_VADDR to the top
of the memory is shadowed here with 1 bit
per byte of memory.
00001000 TASK_SIZE-1 User space mappings
Per-thread mappings are placed here via
the mmap() system call.
00000000 00000fff CPU vector page / null pointer trap
CPUs which do not support vector remapping
place their vector page here. NULL pointer
dereferences by both the kernel and user
space are also caught via this mapping.
=============== =============== ===============================================
Please note that mappings which collide with the above areas may result
in a non-bootable kernel, or may cause the kernel to (eventually) panic
at run time.
Since future CPUs may impact the kernel mapping layout, user programs
must not access any memory which is not mapped inside their 0x0001000
to TASK_SIZE address range. If they wish to access these areas, they
must set up their own mappings using open() and mmap().
linux-7.2.3/Documentation/arch/arm/microchip.rst
+230
View File
@@ -0,0 +1,230 @@
=============================
ARM Microchip SoCs (aka AT91)
=============================
Introduction
------------
This document gives useful information about the ARM Microchip SoCs that are
currently supported in Linux Mainline (you know, the one on kernel.org).
It is important to note that the Microchip (previously Atmel) ARM-based MPU
product line is historically named "AT91" or "at91" throughout the Linux kernel
development process even if this product prefix has completely disappeared from
the official Microchip product name. Anyway, files, directories, git trees,
git branches/tags and email subject always contain this "at91" sub-string.
AT91 SoCs
---------
Documentation and detailed datasheet for each product are available on
the Microchip website: http://www.microchip.com.
Flavors:
* ARM 920 based SoC
- at91rm9200
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-1768-32-bit-ARM920T-Embedded-Microprocessor-AT91RM9200_Datasheet.pdf
* ARM 926 based SoCs
- at91sam9260
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6221-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9260_Datasheet.pdf
- at91sam9xe
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6254-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9XE_Datasheet.pdf
- at91sam9261
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6062-ARM926EJ-S-Microprocessor-SAM9261_Datasheet.pdf
- at91sam9263
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6249-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9263_Datasheet.pdf
- at91sam9rl
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/doc6289.pdf
- at91sam9g20
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001516A.pdf
- at91sam9g45 family
- at91sam9g45
- at91sam9g46
- at91sam9m10
- at91sam9m11 (device superset)
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6437-32-bit-ARM926-Embedded-Microprocessor-SAM9M11_Datasheet.pdf
- at91sam9x5 family (aka "The 5 series")
- at91sam9g15
- at91sam9g25
- at91sam9g35
- at91sam9x25
- at91sam9x35
* Datasheet (can be considered as covering the whole family)
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11055-32-bit-ARM926EJ-S-Microcontroller-SAM9X35_Datasheet.pdf
- at91sam9n12
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001517A.pdf
- sam9x60
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/SAM9X60-Data-Sheet-DS60001579A.pdf
* ARM Cortex-A5 based SoCs
- sama5d3 family
- sama5d31
- sama5d33
- sama5d34
- sama5d35
- sama5d36 (device superset)
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet_B.pdf
* ARM Cortex-A5 + NEON based SoCs
- sama5d4 family
- sama5d41
- sama5d42
- sama5d43
- sama5d44 (device superset)
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/60001525A.pdf
- sama5d2 family
- sama5d21
- sama5d22
- sama5d23
- sama5d24
- sama5d26
- sama5d27 (device superset)
- sama5d28 (device superset + environmental monitors)
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001476B.pdf
* ARM Cortex-A7 based SoCs
- sama7g5 family
- sama7g51
- sama7g52
- sama7g53
- sama7g54 (device superset)
* Datasheet
Coming soon
- lan966 family
- lan9662
- lan9668
* Datasheet
Coming soon
* ARM Cortex-M7 MCUs
- sams70 family
- sams70j19
- sams70j20
- sams70j21
- sams70n19
- sams70n20
- sams70n21
- sams70q19
- sams70q20
- sams70q21
- samv70 family
- samv70j19
- samv70j20
- samv70n19
- samv70n20
- samv70q19
- samv70q20
- samv71 family
- samv71j19
- samv71j20
- samv71j21
- samv71n19
- samv71n20
- samv71n21
- samv71q19
- samv71q20
- samv71q21
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70-S70-V70-V71-Family-Data-Sheet-DS60001527D.pdf
Linux kernel information
------------------------
Linux kernel mach directory: arch/arm/mach-at91
MAINTAINERS entry is: "ARM/Microchip (AT91) SoC support"
Device Tree for AT91 SoCs and boards
------------------------------------
All AT91 SoCs are converted to Device Tree. Since Linux 3.19, these products
must use this method to boot the Linux kernel.
Work In Progress statement:
Device Tree files and Device Tree bindings that apply to AT91 SoCs and boards are
considered as "Unstable". To be completely clear, any at91 binding can change at
any time. So, be sure to use a Device Tree Binary and a Kernel Image generated from
the same source tree.
Please refer to the Documentation/devicetree/bindings/ABI.rst file for a
definition of a "Stable" binding/ABI.
This statement will be removed by AT91 MAINTAINERS when appropriate.
Naming conventions and best practice:
- SoCs Device Tree Source Include files are named after the official name of
the product (at91sam9g20.dtsi or sama5d33.dtsi for instance).
- Device Tree Source Include files (.dtsi) are used to collect common nodes that can be
shared across SoCs or boards (sama5d3.dtsi or at91sam9x5cm.dtsi for instance).
When collecting nodes for a particular peripheral or topic, the identifier have to
be placed at the end of the file name, separated with a "_" (at91sam9x5_can.dtsi
or sama5d3_gmac.dtsi for example).
- board Device Tree Source files (.dts) are prefixed by the string "at91-" so
that they can be identified easily. Note that some files are historical exceptions
to this rule (sama5d3[13456]ek.dts, usb_a9g20.dts or animeo_ip.dts for example).
linux-7.2.3/Documentation/arch/arm/netwinder.rst
+85
View File
@@ -0,0 +1,85 @@
================================
NetWinder specific documentation
================================
The NetWinder is a small low-power computer, primarily designed
to run Linux. It is based around the StrongARM RISC processor,
DC21285 PCI bridge, with PC-type hardware glued around it.
Port usage
==========
======= ====== ===============================
Min Max Description
======= ====== ===============================
0x0000 0x000f DMA1
0x0020 0x0021 PIC1
0x0060 0x006f Keyboard
0x0070 0x007f RTC
0x0080 0x0087 DMA1
0x0088 0x008f DMA2
0x00a0 0x00a3 PIC2
0x00c0 0x00df DMA2
0x0180 0x0187 IRDA
0x01f0 0x01f6 ide0
0x0201 Game port
0x0203 RWA010 configuration read
0x0220 ? SoundBlaster
0x0250 ? WaveArtist
0x0279 RWA010 configuration index
0x02f8 0x02ff Serial ttyS1
0x0300 0x031f Ether10
0x0338 GPIO1
0x033a GPIO2
0x0370 0x0371 W83977F configuration registers
0x0388 ? AdLib
0x03c0 0x03df VGA
0x03f6 ide0
0x03f8 0x03ff Serial ttyS0
0x0400 0x0408 DC21143
0x0480 0x0487 DMA1
0x0488 0x048f DMA2
0x0a79 RWA010 configuration write
0xe800 0xe80f ide0/ide1 BM DMA
======= ====== ===============================
Interrupt usage
===============
======= ======= ========================
IRQ type Description
======= ======= ========================
0 ISA 100Hz timer
1 ISA Keyboard
2 ISA cascade
3 ISA Serial ttyS1
4 ISA Serial ttyS0
5 ISA PS/2 mouse
6 ISA IRDA
7 ISA Printer
8 ISA RTC alarm
9 ISA
10 ISA GP10 (Orange reset button)
11 ISA
12 ISA WaveArtist
13 ISA
14 ISA hda1
15 ISA
======= ======= ========================
DMA usage
=========
======= ======= ===========
DMA type Description
======= ======= ===========
0 ISA IRDA
1 ISA
2 ISA cascade
3 ISA WaveArtist
4 ISA
5 ISA
6 ISA
7 ISA WaveArtist
======= ======= ===========
linux-7.2.3/Documentation/arch/arm/nwfpe/index.rst
+13
View File
@@ -0,0 +1,13 @@
.. SPDX-License-Identifier: GPL-2.0
===================================
NetWinder's floating point emulator
===================================
.. toctree::
:maxdepth: 1
nwfpe
netwinder-fpe
notes
todo
linux-7.2.3/Documentation/arch/arm/nwfpe/netwinder-fpe.rst
+162
View File
@@ -0,0 +1,162 @@
=============
Current State
=============
The following describes the current state of the NetWinder's floating point
emulator.
In the following nomenclature is used to describe the floating point
instructions. It follows the conventions in the ARM manual.
::
<S|D|E> = <single|double|extended>, no default
{P|M|Z} = {round to +infinity,round to -infinity,round to zero},
default = round to nearest
Note: items enclosed in {} are optional.
Floating Point Coprocessor Data Transfer Instructions (CPDT)
------------------------------------------------------------
LDF/STF - load and store floating
<LDF|STF>{cond}<S|D|E> Fd, Rn
<LDF|STF>{cond}<S|D|E> Fd, [Rn, #<expression>]{!}
<LDF|STF>{cond}<S|D|E> Fd, [Rn], #<expression>
These instructions are fully implemented.
LFM/SFM - load and store multiple floating
Form 1 syntax:
<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn]
<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn, #<expression>]{!}
<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn], #<expression>
Form 2 syntax:
<LFM|SFM>{cond}<FD,EA> Fd, <count>, [Rn]{!}
These instructions are fully implemented. They store/load three words
for each floating point register into the memory location given in the
instruction. The format in memory is unlikely to be compatible with
other implementations, in particular the actual hardware. Specific
mention of this is made in the ARM manuals.
Floating Point Coprocessor Register Transfer Instructions (CPRT)
----------------------------------------------------------------
Conversions, read/write status/control register instructions
FLT{cond}<S,D,E>{P,M,Z} Fn, Rd Convert integer to floating point
FIX{cond}{P,M,Z} Rd, Fn Convert floating point to integer
WFS{cond} Rd Write floating point status register
RFS{cond} Rd Read floating point status register
WFC{cond} Rd Write floating point control register
RFC{cond} Rd Read floating point control register
FLT/FIX are fully implemented.
RFS/WFS are fully implemented.
RFC/WFC are fully implemented. RFC/WFC are supervisor only instructions, and
presently check the CPU mode, and do an invalid instruction trap if not called
from supervisor mode.
Compare instructions
CMF{cond} Fn, Fm Compare floating
CMFE{cond} Fn, Fm Compare floating with exception
CNF{cond} Fn, Fm Compare negated floating
CNFE{cond} Fn, Fm Compare negated floating with exception
These are fully implemented.
Floating Point Coprocessor Data Instructions (CPDT)
---------------------------------------------------
Dyadic operations:
ADF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - add
SUF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - subtract
RSF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse subtract
MUF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - multiply
DVF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - divide
RDV{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse divide
These are fully implemented.
FML{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast multiply
FDV{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast divide
FRD{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast reverse divide
These are fully implemented as well. They use the same algorithm as the
non-fast versions. Hence, in this implementation their performance is
equivalent to the MUF/DVF/RDV instructions. This is acceptable according
to the ARM manual. The manual notes these are defined only for single
operands, on the actual FPA11 hardware they do not work for double or
extended precision operands. The emulator currently does not check
the requested permissions conditions, and performs the requested operation.
RMF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - IEEE remainder
This is fully implemented.
Monadic operations:
MVF{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - move
MNF{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - move negated
These are fully implemented.
ABS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - absolute value
SQT{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - square root
RND{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - round
These are fully implemented.
URD{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - unnormalized round
NRM{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - normalize
These are implemented. URD is implemented using the same code as the RND
instruction. Since URD cannot return a unnormalized number, NRM becomes
a NOP.
Library calls:
POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power
RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power
POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2)
LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10
LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e
EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent
SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine
COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine
TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent
ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine
ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine
ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent
These are not implemented. They are not currently issued by the compiler,
and are handled by routines in libc. These are not implemented by the FPA11
hardware, but are handled by the floating point support code. They should
be implemented in future versions.
Signalling:
Signals are implemented. However current ELF kernels produced by Rebel.com
have a bug in them that prevents the module from generating a SIGFPE. This
is caused by a failure to alias fp_current to the kernel variable
current_set[0] correctly.
The kernel provided with this distribution (vmlinux-nwfpe-0.93) contains
a fix for this problem and also incorporates the current version of the
emulator directly. It is possible to run with no floating point module
loaded with this kernel. It is provided as a demonstration of the
technology and for those who want to do floating point work that depends
on signals. It is not strictly necessary to use the module.
A module (either the one provided by Russell King, or the one in this
distribution) can be loaded to replace the functionality of the emulator
built into the kernel.
linux-7.2.3/Documentation/arch/arm/nwfpe/notes.rst
+32
View File
@@ -0,0 +1,32 @@
Notes
=====
There seems to be a problem with exp(double) and our emulator. I haven't
been able to track it down yet. This does not occur with the emulator
supplied by Russell King.
I also found one oddity in the emulator. I don't think it is serious but
will point it out. The ARM calling conventions require floating point
registers f4-f7 to be preserved over a function call. The compiler quite
often uses an stfe instruction to save f4 on the stack upon entry to a
function, and an ldfe instruction to restore it before returning.
I was looking at some code, that calculated a double result, stored it in f4
then made a function call. Upon return from the function call the number in
f4 had been converted to an extended value in the emulator.
This is a side effect of the stfe instruction. The double in f4 had to be
converted to extended, then stored. If an lfm/sfm combination had been used,
then no conversion would occur. This has performance considerations. The
result from the function call and f4 were used in a multiplication. If the
emulator sees a multiply of a double and extended, it promotes the double to
extended, then does the multiply in extended precision.
This code will cause this problem:
double x, y, z;
z = log(x)/log(y);
The result of log(x) (a double) will be calculated, returned in f0, then
moved to f4 to preserve it over the log(y) call. The division will be done
in extended precision, due to the stfe instruction used to save f4 in log(y).
linux-7.2.3/Documentation/arch/arm/nwfpe/nwfpe.rst
+74
View File
@@ -0,0 +1,74 @@
Introduction
============
This directory contains the version 0.92 test release of the NetWinder
Floating Point Emulator.
The majority of the code was written by me, Scott Bambrough It is
written in C, with a small number of routines in inline assembler
where required. It was written quickly, with a goal of implementing a
working version of all the floating point instructions the compiler
emits as the first target. I have attempted to be as optimal as
possible, but there remains much room for improvement.
I have attempted to make the emulator as portable as possible. One of
the problems is with leading underscores on kernel symbols. Elf
kernels have no leading underscores, a.out compiled kernels do. I
have attempted to use the C_SYMBOL_NAME macro wherever this may be
important.
Another choice I made was in the file structure. I have attempted to
contain all operating system specific code in one module (fpmodule.*).
All the other files contain emulator specific code. This should allow
others to port the emulator to NetBSD for instance relatively easily.
The floating point operations are based on SoftFloat Release 2, by
John Hauser. SoftFloat is a software implementation of floating-point
that conforms to the IEC/IEEE Standard for Binary Floating-point
Arithmetic. As many as four formats are supported: single precision,
double precision, extended double precision, and quadruple precision.
All operations required by the standard are implemented, except for
conversions to and from decimal. We use only the single precision,
double precision and extended double precision formats. The port of
SoftFloat to the ARM was done by Phil Blundell, based on an earlier
port of SoftFloat version 1 by Neil Carson for NetBSD/arm32.
The file README.FPE contains a description of what has been implemented
so far in the emulator. The file TODO contains a information on what
remains to be done, and other ideas for the emulator.
Bug reports, comments, suggestions should be directed to me at
<scottb@netwinder.org>. General reports of "this program doesn't
work correctly when your emulator is installed" are useful for
determining that bugs still exist; but are virtually useless when
attempting to isolate the problem. Please report them, but don't
expect quick action. Bugs still exist. The problem remains in isolating
which instruction contains the bug. Small programs illustrating a specific
problem are a godsend.
Legal Notices
-------------
The NetWinder Floating Point Emulator is free software. Everything Rebel.com
has written is provided under the GNU GPL. See the file COPYING for copying
conditions. Excluded from the above is the SoftFloat code. John Hauser's
legal notice for SoftFloat is included below.
-------------------------------------------------------------------------------
SoftFloat Legal Notice
SoftFloat was written by John R. Hauser. This work was made possible in
part by the International Computer Science Institute, located at Suite 600,
1947 Center Street, Berkeley, California 94704. Funding was partially
provided by the National Science Foundation under grant MIP-9311980. The
original version of this code was written as part of a project to build
a fixed-point vector processor in collaboration with the University of
California at Berkeley, overseen by Profs. Nelson Morgan and John Wawrzynek.
THIS SOFTWARE IS DISTRIBUTED AS IS, FOR FREE. Although reasonable effort
has been made to avoid it, THIS SOFTWARE MAY CONTAIN FAULTS THAT WILL AT
TIMES RESULT IN INCORRECT BEHAVIOR. USE OF THIS SOFTWARE IS RESTRICTED TO
PERSONS AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ANY
AND ALL LOSSES, COSTS, OR OTHER PROBLEMS ARISING FROM ITS USE.
-------------------------------------------------------------------------------
linux-7.2.3/Documentation/arch/arm/nwfpe/todo.rst
+72
View File
@@ -0,0 +1,72 @@
TODO LIST
=========
::
POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power
RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power
POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2)
LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10
LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e
EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent
SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine
COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine
TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent
ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine
ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine
ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent
These are not implemented. They are not currently issued by the compiler,
and are handled by routines in libc. These are not implemented by the FPA11
hardware, but are handled by the floating point support code. They should
be implemented in future versions.
There are a couple of ways to approach the implementation of these. One
method would be to use accurate table methods for these routines. I have
a couple of papers by S. Gal from IBM's research labs in Haifa, Israel that
seem to promise extreme accuracy (in the order of 99.8%) and reasonable speed.
These methods are used in GLIBC for some of the transcendental functions.
Another approach, which I know little about is CORDIC. This stands for
Coordinate Rotation Digital Computer, and is a method of computing
transcendental functions using mostly shifts and adds and a few
multiplications and divisions. The ARM excels at shifts and adds,
so such a method could be promising, but requires more research to
determine if it is feasible.
Rounding Methods
----------------
The IEEE standard defines 4 rounding modes. Round to nearest is the
default, but rounding to + or - infinity or round to zero are also allowed.
Many architectures allow the rounding mode to be specified by modifying bits
in a control register. Not so with the ARM FPA11 architecture. To change
the rounding mode one must specify it with each instruction.
This has made porting some benchmarks difficult. It is possible to
introduce such a capability into the emulator. The FPCR contains
bits describing the rounding mode. The emulator could be altered to
examine a flag, which if set forced it to ignore the rounding mode in
the instruction, and use the mode specified in the bits in the FPCR.
This would require a method of getting/setting the flag, and the bits
in the FPCR. This requires a kernel call in ArmLinux, as WFC/RFC are
supervisor only instructions. If anyone has any ideas or comments I
would like to hear them.
NOTE:
pulled out from some docs on ARM floating point, specifically
for the Acorn FPE, but not limited to it:
The floating point control register (FPCR) may only be present in some
implementations: it is there to control the hardware in an implementation-
specific manner, for example to disable the floating point system. The user
mode of the ARM is not permitted to use this register (since the right is
reserved to alter it between implementations) and the WFC and RFC
instructions will trap if tried in user mode.
Hence, the answer is yes, you could do this, but then you will run a high
risk of becoming isolated if and when hardware FP emulation comes out
-- Russell.
linux-7.2.3/Documentation/arch/arm/omap/dss.rst
+372
View File
@@ -0,0 +1,372 @@
=========================
OMAP2/3 Display Subsystem
=========================
This is an almost total rewrite of the OMAP FB driver in drivers/video/omap
(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI,
TV-out and multiple display support, but there are lots of small improvements
also.
The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB,
panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live
currently side by side, you can choose which one to use.
Features
--------
Working and tested features include:
- MIPI DPI (parallel) output
- MIPI DSI output in command mode
- MIPI DBI (RFBI) output
- SDI output
- TV output
- All pieces can be compiled as a module or inside kernel
- Use DISPC to update any of the outputs
- Use CPU to update RFBI or DSI output
- OMAP DISPC planes
- RGB16, RGB24 packed, RGB24 unpacked
- YUV2, UYVY
- Scaling
- Adjusting DSS FCK to find a good pixel clock
- Use DSI DPLL to create DSS FCK
Tested boards include:
- OMAP3 SDP board
- Beagle board
- N810
omapdss driver
--------------
The DSS driver does not itself have any support for Linux framebuffer, V4L or
such like the current ones, but it has an internal kernel API that upper level
drivers can use.
The DSS driver models OMAP's overlays, overlay managers and displays in a
flexible way to enable non-common multi-display configuration. In addition to
modelling the hardware overlays, omapdss supports virtual overlays and overlay
managers. These can be used when updating a display with CPU or system DMA.
omapdss driver support for audio
--------------------------------
There exist several display technologies and standards that support audio as
well. Hence, it is relevant to update the DSS device driver to provide an audio
interface that may be used by an audio driver or any other driver interested in
the functionality.
The audio_enable function is intended to prepare the relevant
IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
some IP, enabling companion chips, etc). It is intended to be called before
audio_start. The audio_disable function performs the reverse operation and is
intended to be called after audio_stop.
While a given DSS device driver may support audio, it is possible that for
certain configurations audio is not supported (e.g., an HDMI display using a
VESA video timing). The audio_supported function is intended to query whether
the current configuration of the display supports audio.
The audio_config function is intended to configure all the relevant audio
parameters of the display. In order to make the function independent of any
specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
is to contain all the required parameters for audio configuration. At the
moment, such structure contains pointers to IEC-60958 channel status word
and CEA-861 audio infoframe structures. This should be enough to support
HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.
The audio_enable/disable, audio_config and audio_supported functions could be
implemented as functions that may sleep. Hence, they should not be called
while holding a spinlock or a readlock.
The audio_start/audio_stop function is intended to effectively start/stop audio
playback after the configuration has taken place. These functions are designed
to be used in an atomic context. Hence, audio_start should return quickly and be
called only after all the needed resources for audio playback (audio FIFOs,
DMA channels, companion chips, etc) have been enabled to begin data transfers.
audio_stop is designed to only stop the audio transfers. The resources used
for playback are released using audio_disable.
The enum omap_dss_audio_state may be used to help the implementations of
the interface to keep track of the audio state. The initial state is _DISABLED;
then, the state transitions to _CONFIGURED, and then, when it is ready to
play audio, to _ENABLED. The state _PLAYING is used when the audio is being
rendered.
Panel and controller drivers
----------------------------
The drivers implement panel or controller specific functionality and are not
usually visible to users except through omapfb driver. They register
themselves to the DSS driver.
omapfb driver
-------------
The omapfb driver implements arbitrary number of standard linux framebuffers.
These framebuffers can be routed flexibly to any overlays, thus allowing very
dynamic display architecture.
The driver exports some omapfb specific ioctls, which are compatible with the
ioctls in the old driver.
The rest of the non standard features are exported via sysfs. Whether the final
implementation will use sysfs, or ioctls, is still open.
V4L2 drivers
------------
V4L2 is being implemented in TI.
From omapdss point of view the V4L2 drivers should be similar to framebuffer
driver.
Architecture
--------------------
Some clarification what the different components do:
- Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the
pixel data for the image. Framebuffer has width and height and color
depth.
- Overlay defines where the pixels are read from and where they go on the
screen. The overlay may be smaller than framebuffer, thus displaying only
part of the framebuffer. The position of the overlay may be changed if
the overlay is smaller than the display.
- Overlay manager combines the overlays in to one image and feeds them to
display.
- Display is the actual physical display device.
A framebuffer can be connected to multiple overlays to show the same pixel data
on all of the overlays. Note that in this case the overlay input sizes must be
the same, but, in case of video overlays, the output size can be different. Any
framebuffer can be connected to any overlay.
An overlay can be connected to one overlay manager. Also DISPC overlays can be
connected only to DISPC overlay managers, and virtual overlays can be only
connected to virtual overlays.
An overlay manager can be connected to one display. There are certain
restrictions which kinds of displays an overlay manager can be connected:
- DISPC TV overlay manager can be only connected to TV display.
- Virtual overlay managers can only be connected to DBI or DSI displays.
- DISPC LCD overlay manager can be connected to all displays, except TV
display.
Sysfs
-----
The sysfs interface is mainly used for testing. I don't think sysfs
interface is the best for this in the final version, but I don't quite know
what would be the best interfaces for these things.
The sysfs interface is divided to two parts: DSS and FB.
/sys/class/graphics/fb? directory:
mirror 0=off, 1=on
rotate Rotation 0-3 for 0, 90, 180, 270 degrees
rotate_type 0 = DMA rotation, 1 = VRFB rotation
overlays List of overlay numbers to which framebuffer pixels go
phys_addr Physical address of the framebuffer
virt_addr Virtual address of the framebuffer
size Size of the framebuffer
/sys/devices/platform/omapdss/overlay? directory:
enabled 0=off, 1=on
input_size width,height (ie. the framebuffer size)
manager Destination overlay manager name
name
output_size width,height
position x,y
screen_width width
global_alpha global alpha 0-255 0=transparent 255=opaque
/sys/devices/platform/omapdss/manager? directory:
display Destination display
name
alpha_blending_enabled 0=off, 1=on
trans_key_enabled 0=off, 1=on
trans_key_type gfx-destination, video-source
trans_key_value transparency color key (RGB24)
default_color default background color (RGB24)
/sys/devices/platform/omapdss/display? directory:
=============== =============================================================
ctrl_name Controller name
mirror 0=off, 1=on
update_mode 0=off, 1=auto, 2=manual
enabled 0=off, 1=on
name
rotate Rotation 0-3 for 0, 90, 180, 270 degrees
timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)
When writing, two special timings are accepted for tv-out:
"pal" and "ntsc"
panel_name
tear_elim Tearing elimination 0=off, 1=on
output_type Output type (video encoder only): "composite" or "svideo"
=============== =============================================================
There are also some debugfs files at <debugfs>/omapdss/ which show information
about clocks and registers.
Examples
--------
The following definitions have been made for the examples below::
ovl0=/sys/devices/platform/omapdss/overlay0
ovl1=/sys/devices/platform/omapdss/overlay1
ovl2=/sys/devices/platform/omapdss/overlay2
mgr0=/sys/devices/platform/omapdss/manager0
mgr1=/sys/devices/platform/omapdss/manager1
lcd=/sys/devices/platform/omapdss/display0
dvi=/sys/devices/platform/omapdss/display1
tv=/sys/devices/platform/omapdss/display2
fb0=/sys/class/graphics/fb0
fb1=/sys/class/graphics/fb1
fb2=/sys/class/graphics/fb2
Default setup on OMAP3 SDP
--------------------------
Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI
and TV-out are not in use. The columns from left to right are:
framebuffers, overlays, overlay managers, displays. Framebuffers are
handled by omapfb, and the rest by the DSS::
FB0 --- GFX -\ DVI
FB1 --- VID1 --+- LCD ---- LCD
FB2 --- VID2 -/ TV ----- TV
Example: Switch from LCD to DVI
-------------------------------
::
w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1`
h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1`
echo "0" > $lcd/enabled
echo "" > $mgr0/display
fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h
# at this point you have to switch the dvi/lcd dip-switch from the omap board
echo "dvi" > $mgr0/display
echo "1" > $dvi/enabled
After this the configuration looks like:::
FB0 --- GFX -\ -- DVI
FB1 --- VID1 --+- LCD -/ LCD
FB2 --- VID2 -/ TV ----- TV
Example: Clone GFX overlay to LCD and TV
----------------------------------------
::
w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1`
h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1`
echo "0" > $ovl0/enabled
echo "0" > $ovl1/enabled
echo "" > $fb1/overlays
echo "0,1" > $fb0/overlays
echo "$w,$h" > $ovl1/output_size
echo "tv" > $ovl1/manager
echo "1" > $ovl0/enabled
echo "1" > $ovl1/enabled
echo "1" > $tv/enabled
After this the configuration looks like (only relevant parts shown)::
FB0 +-- GFX ---- LCD ---- LCD
\- VID1 ---- TV ---- TV
Misc notes
----------
OMAP FB allocates the framebuffer memory using the standard dma allocator. You
can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma
allocator, and if CMA is enabled, you use "cma=" kernel parameter to increase
the global memory area for CMA.
Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.
Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB
does not support mirroring.
VRFB rotation requires much more memory than non-rotated framebuffer, so you
probably need to increase your vram setting before using VRFB rotation. Also,
many applications may not work with VRFB if they do not pay attention to all
framebuffer parameters.
Kernel boot arguments
---------------------
omapfb.mode=<display>:<mode>[,...]
- Default video mode for specified displays. For example,
"dvi:800x400MR-24@60". See drivers/video/fbdev/core/modedb.c.
There are also two special modes: "pal" and "ntsc" that
can be used to tv out.
omapfb.vram=<fbnum>:<size>[@<physaddr>][,...]
- VRAM allocated for a framebuffer. Normally omapfb allocates vram
depending on the display size. With this you can manually allocate
more or define the physical address of each framebuffer. For example,
"1:4M" to allocate 4M for fb1.
omapfb.debug=<y|n>
- Enable debug printing. You have to have OMAPFB debug support enabled
in kernel config.
omapfb.test=<y|n>
- Draw test pattern to framebuffer whenever framebuffer settings change.
You need to have OMAPFB debug support enabled in kernel config.
omapfb.vrfb=<y|n>
- Use VRFB rotation for all framebuffers.
omapfb.rotate=<angle>
- Default rotation applied to all framebuffers.
0 - 0 degree rotation
1 - 90 degree rotation
2 - 180 degree rotation
3 - 270 degree rotation
omapfb.mirror=<y|n>
- Default mirror for all framebuffers. Only works with DMA rotation.
omapdss.def_disp=<display>
- Name of default display, to which all overlays will be connected.
Common examples are "lcd" or "tv".
omapdss.debug=<y|n>
- Enable debug printing. You have to have DSS debug support enabled in
kernel config.
TODO
----
DSS locking
Error checking
- Lots of checks are missing or implemented just as BUG()
System DMA update for DSI
- Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how
to skip the empty byte?)
OMAP1 support
- Not sure if needed
linux-7.2.3/Documentation/arch/arm/omap/index.rst
+12
View File
@@ -0,0 +1,12 @@
.. SPDX-License-Identifier: GPL-2.0
=======
TI OMAP
=======
.. toctree::
:maxdepth: 1
omap
omap_pm
dss
linux-7.2.3/Documentation/arch/arm/omap/omap.rst
+18
View File
@@ -0,0 +1,18 @@
============
OMAP history
============
This file contains documentation for running mainline
kernel on omaps.
====== ======================================================
KERNEL NEW DEPENDENCIES
====== ======================================================
v4.3+ Update is needed for custom .config files to make sure
CONFIG_REGULATOR_PBIAS is enabled for MMC1 to work
properly.
v4.18+ Update is needed for custom .config files to make sure
CONFIG_MMC_SDHCI_OMAP is enabled for all MMC instances
to work in DRA7 and K2G based boards.
====== ======================================================
linux-7.2.3/Documentation/arch/arm/omap/omap_pm.rst
+165
View File
@@ -0,0 +1,165 @@
=====================
The OMAP PM interface
=====================
This document describes the temporary OMAP PM interface. Driver
authors use these functions to communicate minimum latency or
throughput constraints to the kernel power management code.
Over time, the intention is to merge features from the OMAP PM
interface into the Linux PM QoS code.
Drivers need to express PM parameters which:
- support the range of power management parameters present in the TI SRF;
- separate the drivers from the underlying PM parameter
implementation, whether it is the TI SRF or Linux PM QoS or Linux
latency framework or something else;
- specify PM parameters in terms of fundamental units, such as
latency and throughput, rather than units which are specific to OMAP
or to particular OMAP variants;
- allow drivers which are shared with other architectures (e.g.,
DaVinci) to add these constraints in a way which won't affect non-OMAP
systems,
- can be implemented immediately with minimal disruption of other
architectures.
This document proposes the OMAP PM interface, including the following
five power management functions for driver code:
1. Set the maximum MPU wakeup latency::
(*pdata->set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t)
2. Set the maximum device wakeup latency::
(*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t)
3. Set the maximum system DMA transfer start latency (CORE pwrdm)::
(*pdata->set_max_sdma_lat)(struct device *dev, long t)
4. Set the minimum bus throughput needed by a device::
(*pdata->set_min_bus_tput)(struct device *dev, u8 agent_id, unsigned long r)
5. Return the number of times the device has lost context::
(*pdata->get_dev_context_loss_count)(struct device *dev)
Further documentation for all OMAP PM interface functions can be
found in arch/arm/plat-omap/include/mach/omap-pm.h.
The OMAP PM layer is intended to be temporary
---------------------------------------------
The intention is that eventually the Linux PM QoS layer should support
the range of power management features present in OMAP3. As this
happens, existing drivers using the OMAP PM interface can be modified
to use the Linux PM QoS code; and the OMAP PM interface can disappear.
Driver usage of the OMAP PM functions
-------------------------------------
As the 'pdata' in the above examples indicates, these functions are
exposed to drivers through function pointers in driver .platform_data
structures. The function pointers are initialized by the `board-*.c`
files to point to the corresponding OMAP PM functions:
- set_max_dev_wakeup_lat will point to
omap_pm_set_max_dev_wakeup_lat(), etc. Other architectures which do
not support these functions should leave these function pointers set
to NULL. Drivers should use the following idiom::
if (pdata->set_max_dev_wakeup_lat)
(*pdata->set_max_dev_wakeup_lat)(dev, t);
The most common usage of these functions will probably be to specify
the maximum time from when an interrupt occurs, to when the device
becomes accessible. To accomplish this, driver writers should use the
set_max_mpu_wakeup_lat() function to constrain the MPU wakeup
latency, and the set_max_dev_wakeup_lat() function to constrain the
device wakeup latency (from clk_enable() to accessibility). For
example::
/* Limit MPU wakeup latency */
if (pdata->set_max_mpu_wakeup_lat)
(*pdata->set_max_mpu_wakeup_lat)(dev, tc);
/* Limit device powerdomain wakeup latency */
if (pdata->set_max_dev_wakeup_lat)
(*pdata->set_max_dev_wakeup_lat)(dev, td);
/* total wakeup latency in this example: (tc + td) */
The PM parameters can be overwritten by calling the function again
with the new value. The settings can be removed by calling the
function with a t argument of -1 (except in the case of
set_max_bus_tput(), which should be called with an r argument of 0).
The fifth function above, omap_pm_get_dev_context_loss_count(),
is intended as an optimization to allow drivers to determine whether the
device has lost its internal context. If context has been lost, the
driver must restore its internal context before proceeding.
Other specialized interface functions
-------------------------------------
The five functions listed above are intended to be usable by any
device driver. DSPBridge and CPUFreq have a few special requirements.
DSPBridge expresses target DSP performance levels in terms of OPP IDs.
CPUFreq expresses target MPU performance levels in terms of MPU
frequency. The OMAP PM interface contains functions for these
specialized cases to convert that input information (OPPs/MPU
frequency) into the form that the underlying power management
implementation needs:
6. `(*pdata->dsp_get_opp_table)(void)`
7. `(*pdata->dsp_set_min_opp)(u8 opp_id)`
8. `(*pdata->dsp_get_opp)(void)`
9. `(*pdata->cpu_get_freq_table)(void)`
10. `(*pdata->cpu_set_freq)(unsigned long f)`
11. `(*pdata->cpu_get_freq)(void)`
Customizing OPP for platform
============================
Defining CONFIG_PM should enable OPP layer for the silicon
and the registration of OPP table should take place automatically.
However, in special cases, the default OPP table may need to be
tweaked, for e.g.:
* enable default OPPs which are disabled by default, but which
could be enabled on a platform
* Disable an unsupported OPP on the platform
* Define and add a custom opp table entry
in these cases, the board file needs to do additional steps as follows:
arch/arm/mach-omapx/board-xyz.c::
#include "pm.h"
....
static void __init omap_xyz_init_irq(void)
{
....
/* Initialize the default table */
omapx_opp_init();
/* Do customization to the defaults */
....
}
NOTE:
omapx_opp_init will be omap3_opp_init or as required
based on the omap family.
linux-7.2.3/Documentation/arch/arm/porting.rst
+137
View File
@@ -0,0 +1,137 @@
=======
Porting
=======
Taken from list archive at http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.html
Initial definitions
-------------------
The following symbol definitions rely on you knowing the translation that
__virt_to_phys() does for your machine. This macro converts the passed
virtual address to a physical address. Normally, it is simply:
phys = virt - PAGE_OFFSET + PHYS_OFFSET
Decompressor Symbols
--------------------
ZTEXTADDR
Start address of decompressor. There's no point in talking about
virtual or physical addresses here, since the MMU will be off at
the time when you call the decompressor code. You normally call
the kernel at this address to start it booting. This doesn't have
to be located in RAM, it can be in flash or other read-only or
read-write addressable medium.
ZBSSADDR
Start address of zero-initialised work area for the decompressor.
This must be pointing at RAM. The decompressor will zero initialise
this for you. Again, the MMU will be off.
ZRELADDR
This is the address where the decompressed kernel will be written,
and eventually executed. The following constraint must be valid:
__virt_to_phys(TEXTADDR) == ZRELADDR
The initial part of the kernel is carefully coded to be position
independent.
INITRD_PHYS
Physical address to place the initial RAM disk. Only relevant if
you are using the bootpImage stuff (which only works on the old
struct param_struct).
INITRD_VIRT
Virtual address of the initial RAM disk. The following constraint
must be valid:
__virt_to_phys(INITRD_VIRT) == INITRD_PHYS
PARAMS_PHYS
Physical address of the struct param_struct or tag list, giving the
kernel various parameters about its execution environment.
Kernel Symbols
--------------
PHYS_OFFSET
Physical start address of the first bank of RAM.
PAGE_OFFSET
Virtual start address of the first bank of RAM. During the kernel
boot phase, virtual address PAGE_OFFSET will be mapped to physical
address PHYS_OFFSET, along with any other mappings you supply.
This should be the same value as TASK_SIZE.
TASK_SIZE
The maximum size of a user process in bytes. Since user space
always starts at zero, this is the maximum address that a user
process can access+1. The user space stack grows down from this
address.
Any virtual address below TASK_SIZE is deemed to be user process
area, and therefore managed dynamically on a process by process
basis by the kernel. I'll call this the user segment.
Anything above TASK_SIZE is common to all processes. I'll call
this the kernel segment.
(In other words, you can't put IO mappings below TASK_SIZE, and
hence PAGE_OFFSET).
TEXTADDR
Virtual start address of kernel, normally PAGE_OFFSET + 0x8000.
This is where the kernel image ends up. With the latest kernels,
it must be located at 32768 bytes into a 128MB region. Previous
kernels placed a restriction of 256MB here.
DATAADDR
Virtual address for the kernel data segment. Must not be defined
when using the decompressor.
VMALLOC_START / VMALLOC_END
Virtual addresses bounding the vmalloc() area. There must not be
any static mappings in this area; vmalloc will overwrite them.
The addresses must also be in the kernel segment (see above).
Normally, the vmalloc() area starts VMALLOC_OFFSET bytes above the
last virtual RAM address (found using variable high_memory).
VMALLOC_OFFSET
Offset normally incorporated into VMALLOC_START to provide a hole
between virtual RAM and the vmalloc area. We do this to allow
out of bounds memory accesses (eg, something writing off the end
of the mapped memory map) to be caught. Normally set to 8MB.
Architecture Specific Macros
----------------------------
BOOT_MEM(pram,pio,vio)
`pram` specifies the physical start address of RAM. Must always
be present, and should be the same as PHYS_OFFSET.
`pio` is the physical address of an 8MB region containing IO for
use with the debugging macros in arch/arm/kernel/debug-armv.S.
`vio` is the virtual address of the 8MB debugging region.
It is expected that the debugging region will be re-initialised
by the architecture specific code later in the code (via the
MAPIO function).
BOOT_PARAMS
Same as, and see PARAMS_PHYS.
FIXUP(func)
Machine specific fixups, run before memory subsystems have been
initialised.
MAPIO(func)
Machine specific function to map IO areas (including the debug
region above).
INITIRQ(func)
Machine specific function to initialise interrupts.
linux-7.2.3/Documentation/arch/arm/pxa/mfp.rst
+288
View File
@@ -0,0 +1,288 @@
==============================================
MFP Configuration for PXA2xx/PXA3xx Processors
==============================================
Eric Miao <eric.miao@marvell.com>
MFP stands for Multi-Function Pin, which is the pin-mux logic on PXA3xx and
later PXA series processors. This document describes the existing MFP API,
and how board/platform driver authors could make use of it.
Basic Concept
=============
Unlike the GPIO alternate function settings on PXA25x and PXA27x, a new MFP
mechanism is introduced from PXA3xx to completely move the pin-mux functions
out of the GPIO controller. In addition to pin-mux configurations, the MFP
also controls the low power state, driving strength, pull-up/down and event
detection of each pin. Below is a diagram of internal connections between
the MFP logic and the remaining SoC peripherals::
+--------+
| |--(GPIO19)--+
| GPIO | |
| |--(GPIO...) |
+--------+ |
| +---------+
+--------+ +------>| |
| PWM2 |--(PWM_OUT)-------->| MFP |
+--------+ +------>| |-------> to external PAD
| +---->| |
+--------+ | | +-->| |
| SSP2 |---(TXD)----+ | | +---------+
+--------+ | |
| |
+--------+ | |
| Keypad |--(MKOUT4)----+ |
+--------+ |
|
+--------+ |
| UART2 |---(TXD)--------+
+--------+
NOTE: the external pad is named as MFP_PIN_GPIO19, it doesn't necessarily
mean it's dedicated for GPIO19, only as a hint that internally this pin
can be routed from GPIO19 of the GPIO controller.
To better understand the change from PXA25x/PXA27x GPIO alternate function
to this new MFP mechanism, here are several key points:
1. GPIO controller on PXA3xx is now a dedicated controller, same as other
internal controllers like PWM, SSP and UART, with 128 internal signals
which can be routed to external through one or more MFPs (e.g. GPIO<0>
can be routed through either MFP_PIN_GPIO0 as well as MFP_PIN_GPIO0_2,
see arch/arm/mach-pxa/mfp-pxa300.h)
2. Alternate function configuration is removed from this GPIO controller,
the remaining functions are pure GPIO-specific, i.e.
- GPIO signal level control
- GPIO direction control
- GPIO level change detection
3. Low power state for each pin is now controlled by MFP, this means the
PGSRx registers on PXA2xx are now useless on PXA3xx
4. Wakeup detection is now controlled by MFP, PWER does not control the
wakeup from GPIO(s) any more, depending on the sleeping state, ADxER
(as defined in pxa3xx-regs.h) controls the wakeup from MFP
NOTE: with such a clear separation of MFP and GPIO, by GPIO<xx> we normally
mean it is a GPIO signal, and by MFP<xxx> or pin xxx, we mean a physical
pad (or ball).
MFP API Usage
=============
For board code writers, here are some guidelines:
1. include ONE of the following header files in your <board>.c:
- #include "mfp-pxa25x.h"
- #include "mfp-pxa27x.h"
- #include "mfp-pxa300.h"
- #include "mfp-pxa320.h"
- #include "mfp-pxa930.h"
NOTE: only one file in your <board>.c, depending on the processors used,
because pin configuration definitions may conflict in these file (i.e.
same name, different meaning and settings on different processors). E.g.
for zylonite platform, which support both PXA300/PXA310 and PXA320, two
separate files are introduced: zylonite_pxa300.c and zylonite_pxa320.c
(in addition to handle MFP configuration differences, they also handle
the other differences between the two combinations).
NOTE: PXA300 and PXA310 are almost identical in pin configurations (with
PXA310 supporting some additional ones), thus the difference is actually
covered in a single mfp-pxa300.h.
2. prepare an array for the initial pin configurations, e.g.::
static unsigned long mainstone_pin_config[] __initdata = {
/* Chip Select */
GPIO15_nCS_1,
/* LCD - 16bpp Active TFT */
GPIOxx_TFT_LCD_16BPP,
GPIO16_PWM0_OUT, /* Backlight */
/* MMC */
GPIO32_MMC_CLK,
GPIO112_MMC_CMD,
GPIO92_MMC_DAT_0,
GPIO109_MMC_DAT_1,
GPIO110_MMC_DAT_2,
GPIO111_MMC_DAT_3,
...
/* GPIO */
GPIO1_GPIO | WAKEUP_ON_EDGE_BOTH,
};
a) once the pin configurations are passed to pxa{2xx,3xx}_mfp_config(),
and written to the actual registers, they are useless and may discard,
adding '__initdata' will help save some additional bytes here.
b) when there is only one possible pin configurations for a component,
some simplified definitions can be used, e.g. GPIOxx_TFT_LCD_16BPP on
PXA25x and PXA27x processors
c) if by board design, a pin can be configured to wake up the system
from low power state, it can be 'OR'ed with any of:
WAKEUP_ON_EDGE_BOTH
WAKEUP_ON_EDGE_RISE
WAKEUP_ON_EDGE_FALL
WAKEUP_ON_LEVEL_HIGH - specifically for enabling of keypad GPIOs,
to indicate that this pin has the capability of wake-up the system,
and on which edge(s). This, however, doesn't necessarily mean the
pin _will_ wakeup the system, it will only when set_irq_wake() is
invoked with the corresponding GPIO IRQ (GPIO_IRQ(xx) or gpio_to_irq())
and eventually calls gpio_set_wake() for the actual register setting.
d) although PXA3xx MFP supports edge detection on each pin, the
internal logic will only wakeup the system when those specific bits
in ADxER registers are set, which can be well mapped to the
corresponding peripheral, thus set_irq_wake() can be called with
the peripheral IRQ to enable the wakeup.
MFP on PXA3xx
=============
Every external I/O pad on PXA3xx (excluding those for special purpose) has
one MFP logic associated, and is controlled by one MFP register (MFPR).
The MFPR has the following bit definitions (for PXA300/PXA310/PXA320)::
31 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESERVED |PS|PU|PD| DRIVE |SS|SD|SO|EC|EF|ER|--| AF_SEL |
+-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Bit 3: RESERVED
Bit 4: EDGE_RISE_EN - enable detection of rising edge on this pin
Bit 5: EDGE_FALL_EN - enable detection of falling edge on this pin
Bit 6: EDGE_CLEAR - disable edge detection on this pin
Bit 7: SLEEP_OE_N - enable outputs during low power modes
Bit 8: SLEEP_DATA - output data on the pin during low power modes
Bit 9: SLEEP_SEL - selection control for low power modes signals
Bit 13: PULLDOWN_EN - enable the internal pull-down resistor on this pin
Bit 14: PULLUP_EN - enable the internal pull-up resistor on this pin
Bit 15: PULL_SEL - pull state controlled by selected alternate function
(0) or by PULL{UP,DOWN}_EN bits (1)
Bit 0 - 2: AF_SEL - alternate function selection, 8 possibilities, from 0-7
Bit 10-12: DRIVE - drive strength and slew rate
0b000 - fast 1mA
0b001 - fast 2mA
0b002 - fast 3mA
0b003 - fast 4mA
0b004 - slow 6mA
0b005 - fast 6mA
0b006 - slow 10mA
0b007 - fast 10mA
MFP Design for PXA2xx/PXA3xx
============================
Due to the difference of pin-mux handling between PXA2xx and PXA3xx, a unified
MFP API is introduced to cover both series of processors.
The basic idea of this design is to introduce definitions for all possible pin
configurations, these definitions are processor and platform independent, and
the actual API invoked to convert these definitions into register settings and
make them effective there-after.
Files Involved
--------------
- arch/arm/mach-pxa/include/mach/mfp.h
for
1. Unified pin definitions - enum constants for all configurable pins
2. processor-neutral bit definitions for a possible MFP configuration
- arch/arm/mach-pxa/mfp-pxa3xx.h
for PXA3xx specific MFPR register bit definitions and PXA3xx common pin
configurations
- arch/arm/mach-pxa/mfp-pxa2xx.h
for PXA2xx specific definitions and PXA25x/PXA27x common pin configurations
- arch/arm/mach-pxa/mfp-pxa25x.h
arch/arm/mach-pxa/mfp-pxa27x.h
arch/arm/mach-pxa/mfp-pxa300.h
arch/arm/mach-pxa/mfp-pxa320.h
arch/arm/mach-pxa/mfp-pxa930.h
for processor specific definitions
- arch/arm/mach-pxa/mfp-pxa3xx.c
- arch/arm/mach-pxa/mfp-pxa2xx.c
for implementation of the pin configuration to take effect for the actual
processor.
Pin Configuration
-----------------
The following comments are copied from mfp.h (see the actual source code
for most updated info)::
/*
* a possible MFP configuration is represented by a 32-bit integer
*
* bit 0.. 9 - MFP Pin Number (1024 Pins Maximum)
* bit 10..12 - Alternate Function Selection
* bit 13..15 - Drive Strength
* bit 16..18 - Low Power Mode State
* bit 19..20 - Low Power Mode Edge Detection
* bit 21..22 - Run Mode Pull State
*
* to facilitate the definition, the following macros are provided
*
* MFP_CFG_DEFAULT - default MFP configuration value, with
* alternate function = 0,
* drive strength = fast 3mA (MFP_DS03X)
* low power mode = default
* edge detection = none
*
* MFP_CFG - default MFPR value with alternate function
* MFP_CFG_DRV - default MFPR value with alternate function and
* pin drive strength
* MFP_CFG_LPM - default MFPR value with alternate function and
* low power mode
* MFP_CFG_X - default MFPR value with alternate function,
* pin drive strength and low power mode
*/
Examples of pin configurations are::
#define GPIO94_SSP3_RXD MFP_CFG_X(GPIO94, AF1, DS08X, FLOAT)
which reads GPIO94 can be configured as SSP3_RXD, with alternate function
selection of 1, driving strength of 0b101, and a float state in low power
modes.
NOTE: this is the default setting of this pin being configured as SSP3_RXD
which can be modified a bit in board code, though it is not recommended to
do so, simply because this default setting is usually carefully encoded,
and is supposed to work in most cases.
Register Settings
-----------------
Register settings on PXA3xx for a pin configuration is actually very
straight-forward, most bits can be converted directly into MFPR value
in a easier way. Two sets of MFPR values are calculated: the run-time
ones and the low power mode ones, to allow different settings.
The conversion from a generic pin configuration to the actual register
settings on PXA2xx is a bit complicated: many registers are involved,
including GAFRx, GPDRx, PGSRx, PWER, PKWR, PFER and PRER. Please see
mfp-pxa2xx.c for how the conversion is made.
linux-7.2.3/Documentation/arch/arm/sa1100/assabet.rst
+301
View File
@@ -0,0 +1,301 @@
============================================
The Intel Assabet (SA-1110 evaluation) board
============================================
Please see:
http://developer.intel.com
Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>:
http://www.cs.cmu.edu/~wearable/software/assabet.html
Building the kernel
-------------------
To build the kernel with current defaults::
make assabet_defconfig
make oldconfig
make zImage
The resulting kernel image should be available in linux/arch/arm/boot/zImage.
Installing a bootloader
-----------------------
A couple of bootloaders able to boot Linux on Assabet are available:
BLOB (http://www.lartmaker.nl/lartware/blob/)
BLOB is a bootloader used within the LART project. Some contributed
patches were merged into BLOB to add support for Assabet.
Compaq's Bootldr + John Dorsey's patch for Assabet support
(http://www.handhelds.org/Compaq/bootldr.html)
(http://www.wearablegroup.org/software/bootldr/)
Bootldr is the bootloader developed by Compaq for the iPAQ Pocket PC.
John Dorsey has produced add-on patches to add support for Assabet and
the JFFS filesystem.
RedBoot (http://sources.redhat.com/redboot/)
RedBoot is a bootloader developed by Red Hat based on the eCos RTOS
hardware abstraction layer. It supports Assabet amongst many other
hardware platforms.
RedBoot is currently the recommended choice since it's the only one to have
networking support, and is the most actively maintained.
Brief examples on how to boot Linux with RedBoot are shown below. But first
you need to have RedBoot installed in your flash memory. A known to work
precompiled RedBoot binary is available from the following location:
- ftp://ftp.netwinder.org/users/n/nico/
- ftp://ftp.arm.linux.org.uk/pub/linux/arm/people/nico/
- ftp://ftp.handhelds.org/pub/linux/arm/sa-1100-patches/
Look for redboot-assabet*.tgz. Some installation infos are provided in
redboot-assabet*.txt.
Initial RedBoot configuration
-----------------------------
The commands used here are explained in The RedBoot User's Guide available
on-line at http://sources.redhat.com/ecos/docs.html.
Please refer to it for explanations.
If you have a CF network card (my Assabet kit contained a CF+ LP-E from
Socket Communications Inc.), you should strongly consider using it for TFTP
file transfers. You must insert it before RedBoot runs since it can't detect
it dynamically.
To initialize the flash directory::
fis init -f
To initialize the non-volatile settings, like whether you want to use BOOTP or
a static IP address, etc, use this command::
fconfig -i
Writing a kernel image into flash
---------------------------------
First, the kernel image must be loaded into RAM. If you have the zImage file
available on a TFTP server::
load zImage -r -b 0x100000
If you rather want to use Y-Modem upload over the serial port::
load -m ymodem -r -b 0x100000
To write it to flash::
fis create "Linux kernel" -b 0x100000 -l 0xc0000
Booting the kernel
------------------
The kernel still requires a filesystem to boot. A ramdisk image can be loaded
as follows::
load ramdisk_image.gz -r -b 0x800000
Again, Y-Modem upload can be used instead of TFTP by replacing the file name
by '-y ymodem'.
Now the kernel can be retrieved from flash like this::
fis load "Linux kernel"
or loaded as described previously. To boot the kernel::
exec -b 0x100000 -l 0xc0000
The ramdisk image could be stored into flash as well, but there are better
solutions for on-flash filesystems as mentioned below.
Using JFFS2
-----------
Using JFFS2 (the Second Journalling Flash File System) is probably the most
convenient way to store a writable filesystem into flash. JFFS2 is used in
conjunction with the MTD layer which is responsible for low-level flash
management. More information on the Linux MTD can be found on-line at:
http://www.linux-mtd.infradead.org/. A JFFS howto with some infos about
creating JFFS/JFFS2 images is available from the same site.
For instance, a sample JFFS2 image can be retrieved from the same FTP sites
mentioned below for the precompiled RedBoot image.
To load this file::
load sample_img.jffs2 -r -b 0x100000
The result should look like::
RedBoot> load sample_img.jffs2 -r -b 0x100000
Raw file loaded 0x00100000-0x00377424
Now we must know the size of the unallocated flash::
fis free
Result::
RedBoot> fis free
0x500E0000 .. 0x503C0000
The values above may be different depending on the size of the filesystem and
the type of flash. See their usage below as an example and take care of
substituting yours appropriately.
We must determine some values::
size of unallocated flash: 0x503c0000 - 0x500e0000 = 0x2e0000
size of the filesystem image: 0x00377424 - 0x00100000 = 0x277424
We want to fit the filesystem image of course, but we also want to give it all
the remaining flash space as well. To write it::
fis unlock -f 0x500E0000 -l 0x2e0000
fis erase -f 0x500E0000 -l 0x2e0000
fis write -b 0x100000 -l 0x277424 -f 0x500E0000
fis create "JFFS2" -n -f 0x500E0000 -l 0x2e0000
Now the filesystem is associated to a MTD "partition" once Linux has discovered
what they are in the boot process. From Redboot, the 'fis list' command
displays them::
RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
RedBoot 0x50000000 0x50000000 0x00020000 0x00000000
RedBoot config 0x503C0000 0x503C0000 0x00020000 0x00000000
FIS directory 0x503E0000 0x503E0000 0x00020000 0x00000000
Linux kernel 0x50020000 0x00100000 0x000C0000 0x00000000
JFFS2 0x500E0000 0x500E0000 0x002E0000 0x00000000
However Linux should display something like::
SA1100 flash: probing 32-bit flash bus
SA1100 flash: Found 2 x16 devices at 0x0 in 32-bit mode
Using RedBoot partition definition
Creating 5 MTD partitions on "SA1100 flash":
0x00000000-0x00020000 : "RedBoot"
0x00020000-0x000e0000 : "Linux kernel"
0x000e0000-0x003c0000 : "JFFS2"
0x003c0000-0x003e0000 : "RedBoot config"
0x003e0000-0x00400000 : "FIS directory"
What's important here is the position of the partition we are interested in,
which is the third one. Within Linux, this correspond to /dev/mtdblock2.
Therefore to boot Linux with the kernel and its root filesystem in flash, we
need this RedBoot command::
fis load "Linux kernel"
exec -b 0x100000 -l 0xc0000 -c "root=/dev/mtdblock2"
Of course other filesystems than JFFS might be used, like cramfs for example.
You might want to boot with a root filesystem over NFS, etc. It is also
possible, and sometimes more convenient, to flash a filesystem directly from
within Linux while booted from a ramdisk or NFS. The Linux MTD repository has
many tools to deal with flash memory as well, to erase it for example. JFFS2
can then be mounted directly on a freshly erased partition and files can be
copied over directly. Etc...
RedBoot scripting
-----------------
All the commands above aren't so useful if they have to be typed in every
time the Assabet is rebooted. Therefore it's possible to automate the boot
process using RedBoot's scripting capability.
For example, I use this to boot Linux with both the kernel and the ramdisk
images retrieved from a TFTP server on the network::
RedBoot> fconfig
Run script at boot: false true
Boot script:
Enter script, terminate with empty line
>> load zImage -r -b 0x100000
>> load ramdisk_ks.gz -r -b 0x800000
>> exec -b 0x100000 -l 0xc0000
>>
Boot script timeout (1000ms resolution): 3
Use BOOTP for network configuration: true
GDB connection port: 9000
Network debug at boot time: false
Update RedBoot non-volatile configuration - are you sure (y/n)? y
Then, rebooting the Assabet is just a matter of waiting for the login prompt.
Nicolas Pitre
nico@fluxnic.net
June 12, 2001
Status of peripherals in -rmk tree (updated 14/10/2001)
-------------------------------------------------------
Assabet:
Serial ports:
Radio: TX, RX, CTS, DSR, DCD, RI
- PM: Not tested.
- COM: TX, RX, CTS, DSR, DCD, RTS, DTR, PM
- PM: Not tested.
- I2C: Implemented, not fully tested.
- L3: Fully tested, pass.
- PM: Not tested.
Video:
- LCD: Fully tested. PM
(LCD doesn't like being blanked with neponset connected)
- Video out: Not fully
Audio:
UDA1341:
- Playback: Fully tested, pass.
- Record: Implemented, not tested.
- PM: Not tested.
UCB1200:
- Audio play: Implemented, not heavily tested.
- Audio rec: Implemented, not heavily tested.
- Telco audio play: Implemented, not heavily tested.
- Telco audio rec: Implemented, not heavily tested.
- POTS control: No
- Touchscreen: Yes
- PM: Not tested.
Other:
- PCMCIA:
- LPE: Fully tested, pass.
- USB: No
- IRDA:
- SIR: Fully tested, pass.
- FIR: Fully tested, pass.
- PM: Not tested.
Neponset:
Serial ports:
- COM1,2: TX, RX, CTS, DSR, DCD, RTS, DTR
- PM: Not tested.
- USB: Implemented, not heavily tested.
- PCMCIA: Implemented, not heavily tested.
- CF: Implemented, not heavily tested.
- PM: Not tested.
More stuff can be found in the -np (Nicolas Pitre's) tree.
linux-7.2.3/Documentation/arch/arm/sa1100/cerf.rst
+35
View File
@@ -0,0 +1,35 @@
==============
CerfBoard/Cube
==============
*** The StrongARM version of the CerfBoard/Cube has been discontinued ***
The Intrinsyc CerfBoard is a StrongARM 1110-based computer on a board
that measures approximately 2" square. It includes an Ethernet
controller, an RS232-compatible serial port, a USB function port, and
one CompactFlash+ slot on the back. Pictures can be found at the
Intrinsyc website, http://www.intrinsyc.com.
This document describes the support in the Linux kernel for the
Intrinsyc CerfBoard.
Supported in this version
=========================
- CompactFlash+ slot (select PCMCIA in General Setup and any options
that may be required)
- Onboard Crystal CS8900 Ethernet controller (Cerf CS8900A support in
Network Devices)
- Serial ports with a serial console (hardcoded to 38400 8N1)
In order to get this kernel onto your Cerf, you need a server that runs
both BOOTP and TFTP. Detailed instructions should have come with your
evaluation kit on how to use the bootloader. This series of commands
will suffice::
make ARCH=arm CROSS_COMPILE=arm-linux- cerfcube_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux- zImage
make ARCH=arm CROSS_COMPILE=arm-linux- modules
cp arch/arm/boot/zImage <TFTP directory>
support@intrinsyc.com
linux-7.2.3/Documentation/arch/arm/sa1100/index.rst
+13
View File
@@ -0,0 +1,13 @@
.. SPDX-License-Identifier: GPL-2.0
====================
Intel StrongARM 1100
====================
.. toctree::
:maxdepth: 1
assabet
cerf
lart
serial_uart
linux-7.2.3/Documentation/arch/arm/sa1100/lart.rst
+15
View File
@@ -0,0 +1,15 @@
====================================
Linux Advanced Radio Terminal (LART)
====================================
The LART is a small (7.5 x 10cm) SA-1100 board, designed for embedded
applications. It has 32 MB DRAM, 4MB Flash ROM, double RS232 and all
other StrongARM-gadgets. Almost all SA signals are directly accessible
through a number of connectors. The powersupply accepts voltages
between 3.5V and 16V and is overdimensioned to support a range of
daughterboards. A quad Ethernet / IDE / PS2 / sound daughterboard
is under development, with plenty of others in different stages of
planning.
The hardware designs for this board have been released under an open license;
see the LART page at http://www.lartmaker.nl/ for more information.
linux-7.2.3/Documentation/arch/arm/sa1100/serial_uart.rst
+51
View File
@@ -0,0 +1,51 @@
==================
SA1100 serial port
==================
The SA1100 serial port had its major/minor numbers officially assigned::
> Date: Sun, 24 Sep 2000 21:40:27 -0700
> From: H. Peter Anvin <hpa@transmeta.com>
> To: Nicolas Pitre <nico@CAM.ORG>
> Cc: Device List Maintainer <device@lanana.org>
> Subject: Re: device
>
> Okay. Note that device numbers 204 and 205 are used for "low density
> serial devices", so you will have a range of minors on those majors (the
> tty device layer handles this just fine, so you don't have to worry about
> doing anything special.)
>
> So your assignments are:
>
> 204 char Low-density serial ports
> 5 = /dev/ttySA0 SA1100 builtin serial port 0
> 6 = /dev/ttySA1 SA1100 builtin serial port 1
> 7 = /dev/ttySA2 SA1100 builtin serial port 2
>
> 205 char Low-density serial ports (alternate device)
> 5 = /dev/cusa0 Callout device for ttySA0
> 6 = /dev/cusa1 Callout device for ttySA1
> 7 = /dev/cusa2 Callout device for ttySA2
>
You must create those inodes in /dev on the root filesystem used
by your SA1100-based device::
mknod ttySA0 c 204 5
mknod ttySA1 c 204 6
mknod ttySA2 c 204 7
mknod cusa0 c 205 5
mknod cusa1 c 205 6
mknod cusa2 c 205 7
In addition to the creation of the appropriate device nodes above, you
must ensure your user space applications make use of the correct device
name. The classic example is the content of the /etc/inittab file where
you might have a getty process started on ttyS0.
In this case:
- replace occurrences of ttyS0 with ttySA0, ttyS1 with ttySA1, etc.
- don't forget to add 'ttySA0', 'console', or the appropriate tty name
in /etc/securetty for root to be allowed to login as well.
linux-7.2.3/Documentation/arch/arm/samsung/bootloader-interface.rst
+81
View File
@@ -0,0 +1,81 @@
==========================================================
Interface between kernel and boot loaders on Exynos boards
==========================================================
Author: Krzysztof Kozlowski
Date : 6 June 2015
The document tries to describe currently used interface between Linux kernel
and boot loaders on Samsung Exynos based boards. This is not a definition
of interface but rather a description of existing state, a reference
for information purpose only.
In the document "boot loader" means any of following: U-boot, proprietary
SBOOT or any other firmware for ARMv7 and ARMv8 initializing the board before
executing kernel.
1. Non-Secure mode
Address: sysram_ns_base_addr
============= ============================================ ==================
Offset Value Purpose
============= ============================================ ==================
0x08 exynos_cpu_resume_ns, mcpm_entry_point System suspend
0x0c 0x00000bad (Magic cookie) System suspend
0x1c exynos4_secondary_startup Secondary CPU boot
0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot
0x20 0xfcba0d10 (Magic cookie) AFTR
0x24 exynos_cpu_resume_ns AFTR
0x28 + 4*cpu 0x8 (Magic cookie, Exynos3250) AFTR
0x28 0x0 or last value during resume (Exynos542x) System suspend
============= ============================================ ==================
2. Secure mode
Address: sysram_base_addr
============= ============================================ ==================
Offset Value Purpose
============= ============================================ ==================
0x00 exynos4_secondary_startup Secondary CPU boot
0x04 exynos4_secondary_startup (Exynos542x) Secondary CPU boot
4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot
0x20 exynos_cpu_resume (Exynos4210 r1.0) AFTR
0x24 0xfcba0d10 (Magic cookie, Exynos4210 r1.0) AFTR
============= ============================================ ==================
Address: pmu_base_addr
============= ============================================ ==================
Offset Value Purpose
============= ============================================ ==================
0x0800 exynos_cpu_resume AFTR, suspend
0x0800 mcpm_entry_point (Exynos542x with MCPM) AFTR, suspend
0x0804 0xfcba0d10 (Magic cookie) AFTR
0x0804 0x00000bad (Magic cookie) System suspend
0x0814 exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot
0x0818 0xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR
0x081C exynos_cpu_resume (Exynos4210 r1.1) AFTR
============= ============================================ ==================
3. Other (regardless of secure/non-secure mode)
Address: pmu_base_addr
============= =============================== ===============================
Offset Value Purpose
============= =============================== ===============================
0x0908 Non-zero Secondary CPU boot up indicator
on Exynos3250 and Exynos542x
============= =============================== ===============================
4. Glossary
AFTR - ARM Off Top Running, a low power mode, Cortex cores and many other
modules are power gated, except the TOP modules
MCPM - Multi-Cluster Power Management
linux-7.2.3/Documentation/arch/arm/samsung/clksrc-change-registers.awk
Executable
+166
View File
@@ -0,0 +1,166 @@
#!/usr/bin/awk -f
#
# Copyright 2010 Ben Dooks <ben-linux@fluff.org>
#
# Released under GPLv2
# example usage
# ./clksrc-change-registers.awk arch/arm/plat-s5pc1xx/include/plat/regs-clock.h < src > dst
function extract_value(s)
{
eqat = index(s, "=")
comat = index(s, ",")
return substr(s, eqat+2, (comat-eqat)-2)
}
function remove_brackets(b)
{
return substr(b, 2, length(b)-2)
}
function splitdefine(l, p)
{
r = split(l, tp)
p[0] = tp[2]
p[1] = remove_brackets(tp[3])
}
function find_length(f)
{
if (0)
printf "find_length " f "\n" > "/dev/stderr"
if (f ~ /0x1/)
return 1
else if (f ~ /0x3/)
return 2
else if (f ~ /0x7/)
return 3
else if (f ~ /0xf/)
return 4
printf "unknown length " f "\n" > "/dev/stderr"
exit
}
function find_shift(s)
{
id = index(s, "<")
if (id <= 0) {
printf "cannot find shift " s "\n" > "/dev/stderr"
exit
}
return substr(s, id+2)
}
BEGIN {
if (ARGC < 2) {
print "too few arguments" > "/dev/stderr"
exit
}
# read the header file and find the mask values that we will need
# to replace and create an associative array of values
while (getline line < ARGV[1] > 0) {
if (line ~ /\#define.*_MASK/ &&
!(line ~ /USB_SIG_MASK/)) {
splitdefine(line, fields)
name = fields[0]
if (0)
printf "MASK " line "\n" > "/dev/stderr"
dmask[name,0] = find_length(fields[1])
dmask[name,1] = find_shift(fields[1])
if (0)
printf "=> '" name "' LENGTH=" dmask[name,0] " SHIFT=" dmask[name,1] "\n" > "/dev/stderr"
} else {
}
}
delete ARGV[1]
}
/clksrc_clk.*=.*{/ {
shift=""
mask=""
divshift=""
reg_div=""
reg_src=""
indent=1
print $0
for(; indent >= 1;) {
if ((getline line) <= 0) {
printf "unexpected end of file" > "/dev/stderr"
exit 1;
}
if (line ~ /\.shift/) {
shift = extract_value(line)
} else if (line ~ /\.mask/) {
mask = extract_value(line)
} else if (line ~ /\.reg_divider/) {
reg_div = extract_value(line)
} else if (line ~ /\.reg_source/) {
reg_src = extract_value(line)
} else if (line ~ /\.divider_shift/) {
divshift = extract_value(line)
} else if (line ~ /{/) {
indent++
print line
} else if (line ~ /}/) {
indent--
if (indent == 0) {
if (0) {
printf "shift '" shift "' ='" dmask[shift,0] "'\n" > "/dev/stderr"
printf "mask '" mask "'\n" > "/dev/stderr"
printf "dshft '" divshift "'\n" > "/dev/stderr"
printf "rdiv '" reg_div "'\n" > "/dev/stderr"
printf "rsrc '" reg_src "'\n" > "/dev/stderr"
}
generated = mask
sub(reg_src, reg_div, generated)
if (0) {
printf "/* rsrc " reg_src " */\n"
printf "/* rdiv " reg_div " */\n"
printf "/* shift " shift " */\n"
printf "/* mask " mask " */\n"
printf "/* generated " generated " */\n"
}
if (reg_div != "") {
printf "\t.reg_div = { "
printf ".reg = " reg_div ", "
printf ".shift = " dmask[generated,1] ", "
printf ".size = " dmask[generated,0] ", "
printf "},\n"
}
printf "\t.reg_src = { "
printf ".reg = " reg_src ", "
printf ".shift = " dmask[mask,1] ", "
printf ".size = " dmask[mask,0] ", "
printf "},\n"
}
print line
} else {
print line
}
if (0)
printf indent ":" line "\n" > "/dev/stderr"
}
}
// && ! /clksrc_clk.*=.*{/ { print $0 }}
linux-7.2.3/Documentation/arch/arm/samsung/gpio.rst
+32
View File
@@ -0,0 +1,32 @@
===========================
Samsung GPIO implementation
===========================
Introduction
------------
This outlines the Samsung GPIO implementation and the architecture
specific calls provided alongside the drivers/gpio core.
GPIOLIB integration
-------------------
The gpio implementation uses gpiolib as much as possible, only providing
specific calls for the items that require Samsung specific handling, such
as pin special-function or pull resistor control.
GPIO numbering is synchronised between the Samsung and gpiolib system.
PIN configuration
-----------------
Pin configuration is specific to the Samsung architecture, with each SoC
registering the necessary information for the core gpio configuration
implementation to configure pins as necessary.
The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a
driver or machine to change gpio configuration.
See arch/arm/mach-s3c/gpio-cfg.h for more information on these functions.
linux-7.2.3/Documentation/arch/arm/samsung/index.rst
+12
View File
@@ -0,0 +1,12 @@
.. SPDX-License-Identifier: GPL-2.0
===========
Samsung SoC
===========
.. toctree::
:maxdepth: 1
gpio
bootloader-interface
overview
linux-7.2.3/Documentation/arch/arm/samsung/overview.rst
+76
View File
@@ -0,0 +1,76 @@
==========================
Samsung ARM Linux Overview
==========================
Introduction
------------
The Samsung range of ARM SoCs spans many similar devices, from the initial
ARM9 through to the newest ARM cores. This document shows an overview of
the current kernel support, how to use it and where to find the code
that supports this.
The currently supported SoCs are:
- S3C64XX: S3C6400 and S3C6410
- S5PC110 / S5PV210
Configuration
-------------
A number of configurations are supplied, as there is no current way of
unifying all the SoCs into one kernel.
s5pc110_defconfig
- S5PC110 specific default configuration
s5pv210_defconfig
- S5PV210 specific default configuration
Layout
------
The directory layout is currently being restructured, and consists of
several platform directories and then the machine specific directories
of the CPUs being built for.
plat-samsung provides the base for all the implementations, and is the
last in the line of include directories that are processed for the build
specific information. It contains the base clock, GPIO and device definitions
to get the system running.
plat-s5p is for s5p specific builds, and contains common support for the
S5P specific systems. Not all S5Ps use all the features in this directory
due to differences in the hardware.
Layout changes
--------------
The old plat-s3c and plat-s5pc1xx directories have been removed, with
support moved to either plat-samsung or plat-s5p as necessary. These moves
where to simplify the include and dependency issues involved with having
so many different platform directories.
Port Contributors
-----------------
Ben Dooks (BJD)
Vincent Sanders
Herbert Potzl
Arnaud Patard (RTP)
Roc Wu
Klaus Fetscher
Dimitry Andric
Shannon Holland
Guillaume Gourat (NexVision)
Christer Weinigel (wingel) (Acer N30)
Lucas Correia Villa Real (S3C2400 port)
Document Author
---------------
Copyright 2009-2010 Ben Dooks <ben-linux@fluff.org>
linux-7.2.3/Documentation/arch/arm/setup.rst
+108
View File
@@ -0,0 +1,108 @@
=============================================
Kernel initialisation parameters on ARM Linux
=============================================
The following document describes the kernel initialisation parameter
structure, otherwise known as 'struct param_struct' which is used
for most ARM Linux architectures.
This structure is used to pass initialisation parameters from the
kernel loader to the Linux kernel proper, and may be short lived
through the kernel initialisation process. As a general rule, it
should not be referenced outside of arch/arm/kernel/setup.c:setup_arch().
There are a lot of parameters listed in there, and they are described
below:
page_size
This parameter must be set to the page size of the machine, and
will be checked by the kernel.
nr_pages
This is the total number of pages of memory in the system. If
the memory is banked, then this should contain the total number
of pages in the system.
If the system contains separate VRAM, this value should not
include this information.
ramdisk_size
This is now obsolete, and should not be used.
flags
Various kernel flags, including:
===== ========================
bit 0 1 = mount root read only
bit 1 unused
bit 2 0 = load ramdisk
bit 3 0 = prompt for ramdisk
===== ========================
rootdev
major/minor number pair of device to mount as the root filesystem.
video_num_cols / video_num_rows
These two together describe the character size of the dummy console,
or VGA console character size. They should not be used for any other
purpose.
It's generally a good idea to set these to be either standard VGA, or
the equivalent character size of your fbcon display. This then allows
all the bootup messages to be displayed correctly.
video_x / video_y
This describes the character position of cursor on VGA console, and
is otherwise unused. (should not be used for other console types, and
should not be used for other purposes).
memc_control_reg
MEMC chip control register for Acorn Archimedes and Acorn A5000
based machines. May be used differently by different architectures.
sounddefault
Default sound setting on Acorn machines. May be used differently by
different architectures.
adfsdrives
Number of ADFS/MFM disks. May be used differently by different
architectures.
bytes_per_char_h / bytes_per_char_v
These are now obsolete, and should not be used.
pages_in_bank[4]
Number of pages in each bank of the systems memory (used for RiscPC).
This is intended to be used on systems where the physical memory
is non-contiguous from the processors point of view.
pages_in_vram
Number of pages in VRAM (used on Acorn RiscPC). This value may also
be used by loaders if the size of the video RAM can't be obtained
from the hardware.
initrd_start / initrd_size
This describes the kernel virtual start address and size of the
initial ramdisk.
rd_start
Start address in sectors of the ramdisk image on a floppy disk.
system_rev
system revision number.
system_serial_low / system_serial_high
system 64-bit serial number
mem_fclk_21285
The speed of the external oscillator to the 21285 (footbridge),
which control's the speed of the memory bus, timer & serial port.
Depending upon the speed of the cpu its value can be between
0-66 MHz. If no params are passed or a value of zero is passed,
then a value of 50 Mhz is the default on 21285 architectures.
paths[8][128]
These are now obsolete, and should not be used.
commandline
Kernel command line parameters. Details can be found elsewhere.
linux-7.2.3/Documentation/arch/arm/spear/overview.rst
+66
View File
@@ -0,0 +1,66 @@
========================
SPEAr ARM Linux Overview
========================
Introduction
------------
SPEAr (Structured Processor Enhanced Architecture).
weblink : http://www.st.com/spear
The ST Microelectronics SPEAr range of ARM9/CortexA9 System-on-Chip CPUs are
supported by the 'spear' platform of ARM Linux. Currently SPEAr1310,
SPEAr1340, SPEAr300, SPEAr310, SPEAr320 and SPEAr600 SOCs are supported.
Hierarchy in SPEAr is as follows:
SPEAr (Platform)
- SPEAr3XX (3XX SOC series, based on ARM9)
- SPEAr300 (SOC)
- SPEAr300 Evaluation Board
- SPEAr310 (SOC)
- SPEAr310 Evaluation Board
- SPEAr320 (SOC)
- SPEAr320 Evaluation Board
- SPEAr6XX (6XX SOC series, based on ARM9)
- SPEAr600 (SOC)
- SPEAr600 Evaluation Board
- SPEAr13XX (13XX SOC series, based on ARM CORTEXA9)
- SPEAr1310 (SOC)
- SPEAr1310 Evaluation Board
- SPEAr1340 (SOC)
- SPEAr1340 Evaluation Board
Configuration
-------------
A generic configuration is provided for each machine, and can be used as the
default by::
make spear13xx_defconfig
make spear3xx_defconfig
make spear6xx_defconfig
Layout
------
The common files for multiple machine families (SPEAr3xx, SPEAr6xx and
SPEAr13xx) are located in the platform code contained in arch/arm/plat-spear
with headers in plat/.
Each machine series have a directory with name arch/arm/mach-spear followed by
series name. Like mach-spear3xx, mach-spear6xx and mach-spear13xx.
Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c, for
spear6xx is mach-spear6xx/spear6xx.c and for spear13xx family is
mach-spear13xx/spear13xx.c. mach-spear* also contain soc/machine specific
files, like spear1310.c, spear1340.c spear300.c, spear310.c, spear320.c and
spear600.c. mach-spear* doesn't contains board specific files as they fully
support Flattened Device Tree.
Document Author
---------------
Viresh Kumar <vireshk@kernel.org>, (c) 2010-2012 ST Microelectronics
linux-7.2.3/Documentation/arch/arm/sti/overview.rst
+32
View File
@@ -0,0 +1,32 @@
======================
STi ARM Linux Overview
======================
Introduction
------------
The ST Microelectronics Multimedia and Application Processors range of
CortexA9 System-on-Chip are supported by the 'STi' platform of
ARM Linux. Currently STiH407, STiH410 and STiH418 are supported.
configuration
-------------
The configuration for the STi platform is supported via the multi_v7_defconfig.
Layout
------
All the files for multiple machine families (STiH407, STiH410, and STiH418)
are located in the platform code contained in arch/arm/mach-sti
There is a generic board board-dt.c in the mach folder which support
Flattened Device Tree, which means, It works with any compatible board with
Device Trees.
Document Author
---------------
Srinivas Kandagatla <srinivas.kandagatla@st.com>, (c) 2013 ST Microelectronics
linux-7.2.3/Documentation/arch/arm/sti/stih407-overview.rst
+19
View File
@@ -0,0 +1,19 @@
================
STiH407 Overview
================
Introduction
------------
The STiH407 is the new generation of SoC for Multi-HD, AVC set-top boxes
and server/connected client application for satellite, cable, terrestrial
and IP-STB markets.
Features
- ARM Cortex-A9 1.5 GHz dual core CPU (28nm)
- SATA2, USB 3.0, PCIe, Gbit Ethernet
Document Author
---------------
Maxime Coquelin <maxime.coquelin@st.com>, (c) 2014 ST Microelectronics
linux-7.2.3/Documentation/arch/arm/sti/stih418-overview.rst
+21
View File
@@ -0,0 +1,21 @@
================
STiH418 Overview
================
Introduction
------------
The STiH418 is the new generation of SoC for UHDp60 set-top boxes
and server/connected client application for satellite, cable, terrestrial
and IP-STB markets.
Features
- ARM Cortex-A9 1.5 GHz quad core CPU (28nm)
- SATA2, USB 3.0, PCIe, Gbit Ethernet
- HEVC L5.1 Main 10
- VP9
Document Author
---------------
Maxime Coquelin <maxime.coquelin@st.com>, (c) 2015 ST Microelectronics
linux-7.2.3/Documentation/arch/arm/stm32/overview.rst
+34
View File
@@ -0,0 +1,34 @@
========================
STM32 ARM Linux Overview
========================
Introduction
------------
The STMicroelectronics STM32 family of Cortex-A microprocessors (MPUs) and
Cortex-M microcontrollers (MCUs) are supported by the 'STM32' platform of
ARM Linux.
Configuration
-------------
For MCUs, use the provided default configuration:
make stm32_defconfig
For MPUs, use multi_v7 configuration:
make multi_v7_defconfig
Layout
------
All the files for multiple machine families are located in the platform code
contained in arch/arm/mach-stm32
There is a generic board board-dt.c in the mach folder which support
Flattened Device Tree, which means, it works with any compatible board with
Device Trees.
:Authors:
- Maxime Coquelin <mcoquelin.stm32@gmail.com>
- Ludovic Barre <ludovic.barre@st.com>
- Gerald Baeza <gerald.baeza@st.com>
linux-7.2.3/Documentation/arch/arm/stm32/stm32-dma-mdma-chaining.rst
+415
View File
@@ -0,0 +1,415 @@
.. SPDX-License-Identifier: GPL-2.0
=======================
STM32 DMA-MDMA chaining
=======================
Introduction
------------
This document describes the STM32 DMA-MDMA chaining feature. But before going
further, let's introduce the peripherals involved.
To offload data transfers from the CPU, STM32 microprocessors (MPUs) embed
direct memory access controllers (DMA).
STM32MP1 SoCs embed both STM32 DMA and STM32 MDMA controllers. STM32 DMA
request routing capabilities are enhanced by a DMA request multiplexer
(STM32 DMAMUX).
**STM32 DMAMUX**
STM32 DMAMUX routes any DMA request from a given peripheral to any STM32 DMA
controller (STM32MP1 counts two STM32 DMA controllers) channels.
**STM32 DMA**
STM32 DMA is mainly used to implement central data buffer storage (usually in
the system SRAM) for different peripheral. It can access external RAMs but
without the ability to generate convenient burst transfer ensuring the best
load of the AXI.
**STM32 MDMA**
STM32 MDMA (Master DMA) is mainly used to manage direct data transfers between
RAM data buffers without CPU intervention. It can also be used in a
hierarchical structure that uses STM32 DMA as first level data buffer
interfaces for AHB peripherals, while the STM32 MDMA acts as a second level
DMA with better performance. As a AXI/AHB master, STM32 MDMA can take control
of the AXI/AHB bus.
Principles
----------
STM32 DMA-MDMA chaining feature relies on the strengths of STM32 DMA and
STM32 MDMA controllers.
STM32 DMA has a circular Double Buffer Mode (DBM). At each end of transaction
(when DMA data counter - DMA_SxNDTR - reaches 0), the memory pointers
(configured with DMA_SxSM0AR and DMA_SxM1AR) are swapped and the DMA data
counter is automatically reloaded. This allows the SW or the STM32 MDMA to
process one memory area while the second memory area is being filled/used by
the STM32 DMA transfer.
With STM32 MDMA linked-list mode, a single request initiates the data array
(collection of nodes) to be transferred until the linked-list pointer for the
channel is null. The channel transfer complete of the last node is the end of
transfer, unless first and last nodes are linked to each other, in such a
case, the linked-list loops on to create a circular MDMA transfer.
STM32 MDMA has direct connections with STM32 DMA. This enables autonomous
communication and synchronization between peripherals, thus saving CPU
resources and bus congestion. Transfer Complete signal of STM32 DMA channel
can triggers STM32 MDMA transfer. STM32 MDMA can clear the request generated
by the STM32 DMA by writing to its Interrupt Clear register (whose address is
stored in MDMA_CxMAR, and bit mask in MDMA_CxMDR).
.. table:: STM32 MDMA interconnect table with STM32 DMA
+--------------+----------------+-----------+------------+
| STM32 DMAMUX | STM32 DMA | STM32 DMA | STM32 MDMA |
| channels | channels | Transfer | request |
| | | complete | |
| | | signal | |
+==============+================+===========+============+
| Channel *0* | DMA1 channel 0 | dma1_tcf0 | *0x00* |
+--------------+----------------+-----------+------------+
| Channel *1* | DMA1 channel 1 | dma1_tcf1 | *0x01* |
+--------------+----------------+-----------+------------+
| Channel *2* | DMA1 channel 2 | dma1_tcf2 | *0x02* |
+--------------+----------------+-----------+------------+
| Channel *3* | DMA1 channel 3 | dma1_tcf3 | *0x03* |
+--------------+----------------+-----------+------------+
| Channel *4* | DMA1 channel 4 | dma1_tcf4 | *0x04* |
+--------------+----------------+-----------+------------+
| Channel *5* | DMA1 channel 5 | dma1_tcf5 | *0x05* |
+--------------+----------------+-----------+------------+
| Channel *6* | DMA1 channel 6 | dma1_tcf6 | *0x06* |
+--------------+----------------+-----------+------------+
| Channel *7* | DMA1 channel 7 | dma1_tcf7 | *0x07* |
+--------------+----------------+-----------+------------+
| Channel *8* | DMA2 channel 0 | dma2_tcf0 | *0x08* |
+--------------+----------------+-----------+------------+
| Channel *9* | DMA2 channel 1 | dma2_tcf1 | *0x09* |
+--------------+----------------+-----------+------------+
| Channel *10* | DMA2 channel 2 | dma2_tcf2 | *0x0A* |
+--------------+----------------+-----------+------------+
| Channel *11* | DMA2 channel 3 | dma2_tcf3 | *0x0B* |
+--------------+----------------+-----------+------------+
| Channel *12* | DMA2 channel 4 | dma2_tcf4 | *0x0C* |
+--------------+----------------+-----------+------------+
| Channel *13* | DMA2 channel 5 | dma2_tcf5 | *0x0D* |
+--------------+----------------+-----------+------------+
| Channel *14* | DMA2 channel 6 | dma2_tcf6 | *0x0E* |
+--------------+----------------+-----------+------------+
| Channel *15* | DMA2 channel 7 | dma2_tcf7 | *0x0F* |
+--------------+----------------+-----------+------------+
STM32 DMA-MDMA chaining feature then uses a SRAM buffer. STM32MP1 SoCs embed
three fast access static internal RAMs of various size, used for data storage.
Due to STM32 DMA legacy (within microcontrollers), STM32 DMA performances are
bad with DDR, while they are optimal with SRAM. Hence the SRAM buffer used
between STM32 DMA and STM32 MDMA. This buffer is split in two equal periods
and STM32 DMA uses one period while STM32 MDMA uses the other period
simultaneously.
::
dma[1:2]-tcf[0:7]
.----------------.
____________ ' _________ V____________
| STM32 DMA | / __|>_ \ | STM32 MDMA |
|------------| | / \ | |------------|
| DMA_SxM0AR |<=>| | SRAM | |<=>| []-[]...[] |
| DMA_SxM1AR | | \_____/ | | |
|____________| \___<|____/ |____________|
STM32 DMA-MDMA chaining uses (struct dma_slave_config).peripheral_config to
exchange the parameters needed to configure MDMA. These parameters are
gathered into a u32 array with three values:
* the STM32 MDMA request (which is actually the DMAMUX channel ID),
* the address of the STM32 DMA register to clear the Transfer Complete
interrupt flag,
* the mask of the Transfer Complete interrupt flag of the STM32 DMA channel.
Device Tree updates for STM32 DMA-MDMA chaining support
-------------------------------------------------------
**1. Allocate a SRAM buffer**
SRAM device tree node is defined in SoC device tree. You can refer to it in
your board device tree to define your SRAM pool.
::
&sram {
my_foo_device_dma_pool: dma-sram@0 {
reg = <0x0 0x1000>;
};
};
Be careful of the start index, in case there are other SRAM consumers.
Define your pool size strategically: to optimise chaining, the idea is that
STM32 DMA and STM32 MDMA can work simultaneously, on each buffer of the
SRAM.
If the SRAM period is greater than the expected DMA transfer, then STM32 DMA
and STM32 MDMA will work sequentially instead of simultaneously. It is not a
functional issue but it is not optimal.
Don't forget to refer to your SRAM pool in your device node. You need to
define a new property.
::
&my_foo_device {
...
my_dma_pool = &my_foo_device_dma_pool;
};
Then get this SRAM pool in your foo driver and allocate your SRAM buffer.
**2. Allocate a STM32 DMA channel and a STM32 MDMA channel**
You need to define an extra channel in your device tree node, in addition to
the one you should already have for "classic" DMA operation.
This new channel must be taken from STM32 MDMA channels, so, the phandle of
the DMA controller to use is the MDMA controller's one.
::
&my_foo_device {
[...]
my_dma_pool = &my_foo_device_dma_pool;
dmas = <&dmamux1 ...>, // STM32 DMA channel
<&mdma1 0 0x3 0x1200000a 0 0>; // + STM32 MDMA channel
};
Concerning STM32 MDMA bindings:
1. The request line number : whatever the value here, it will be overwritten
by MDMA driver with the STM32 DMAMUX channel ID passed through
(struct dma_slave_config).peripheral_config
2. The priority level : choose Very High (0x3) so that your channel will
take priority other the other during request arbitration
3. A 32bit mask specifying the DMA channel configuration : source and
destination address increment, block transfer with 128 bytes per single
transfer
4. The 32bit value specifying the register to be used to acknowledge the
request: it will be overwritten by MDMA driver, with the DMA channel
interrupt flag clear register address passed through
(struct dma_slave_config).peripheral_config
5. The 32bit mask specifying the value to be written to acknowledge the
request: it will be overwritten by MDMA driver, with the DMA channel
Transfer Complete flag passed through
(struct dma_slave_config).peripheral_config
Driver updates for STM32 DMA-MDMA chaining support in foo driver
----------------------------------------------------------------
**0. (optional) Refactor the original sg_table if dmaengine_prep_slave_sg()**
In case of dmaengine_prep_slave_sg(), the original sg_table can't be used as
is. Two new sg_tables must be created from the original one. One for
STM32 DMA transfer (where memory address targets now the SRAM buffer instead
of DDR buffer) and one for STM32 MDMA transfer (where memory address targets
the DDR buffer).
The new sg_list items must fit SRAM period length. Here is an example for
DMA_DEV_TO_MEM:
::
/*
* Assuming sgl and nents, respectively the initial scatterlist and its
* length.
* Assuming sram_dma_buf and sram_period, respectively the memory
* allocated from the pool for DMA usage, and the length of the period,
* which is half of the sram_buf size.
*/
struct sg_table new_dma_sgt, new_mdma_sgt;
struct scatterlist *s, *_sgl;
dma_addr_t ddr_dma_buf;
u32 new_nents = 0, len;
int i;
/* Count the number of entries needed */
for_each_sg(sgl, s, nents, i)
if (sg_dma_len(s) > sram_period)
new_nents += DIV_ROUND_UP(sg_dma_len(s), sram_period);
else
new_nents++;
/* Create sg table for STM32 DMA channel */
ret = sg_alloc_table(&new_dma_sgt, new_nents, GFP_ATOMIC);
if (ret)
dev_err(dev, "DMA sg table alloc failed\n");
for_each_sg(new_dma_sgt.sgl, s, new_dma_sgt.nents, i) {
_sgl = sgl;
sg_dma_len(s) = min(sg_dma_len(_sgl), sram_period);
/* Targets the beginning = first half of the sram_buf */
s->dma_address = sram_buf;
/*
* Targets the second half of the sram_buf
* for odd indexes of the item of the sg_list
*/
if (i & 1)
s->dma_address += sram_period;
}
/* Create sg table for STM32 MDMA channel */
ret = sg_alloc_table(&new_mdma_sgt, new_nents, GFP_ATOMIC);
if (ret)
dev_err(dev, "MDMA sg_table alloc failed\n");
_sgl = sgl;
len = sg_dma_len(sgl);
ddr_dma_buf = sg_dma_address(sgl);
for_each_sg(mdma_sgt.sgl, s, mdma_sgt.nents, i) {
size_t bytes = min_t(size_t, len, sram_period);
sg_dma_len(s) = bytes;
sg_dma_address(s) = ddr_dma_buf;
len -= bytes;
if (!len && sg_next(_sgl)) {
_sgl = sg_next(_sgl);
len = sg_dma_len(_sgl);
ddr_dma_buf = sg_dma_address(_sgl);
} else {
ddr_dma_buf += bytes;
}
}
Don't forget to release these new sg_tables after getting the descriptors
with dmaengine_prep_slave_sg().
**1. Set controller specific parameters**
First, use dmaengine_slave_config() with a struct dma_slave_config to
configure STM32 DMA channel. You just have to take care of DMA addresses,
the memory address (depending on the transfer direction) must point on your
SRAM buffer, and set (struct dma_slave_config).peripheral_size != 0.
STM32 DMA driver will check (struct dma_slave_config).peripheral_size to
determine if chaining is being used or not. If it is used, then STM32 DMA
driver fills (struct dma_slave_config).peripheral_config with an array of
three u32 : the first one containing STM32 DMAMUX channel ID, the second one
the channel interrupt flag clear register address, and the third one the
channel Transfer Complete flag mask.
Then, use dmaengine_slave_config with another struct dma_slave_config to
configure STM32 MDMA channel. Take care of DMA addresses, the device address
(depending on the transfer direction) must point on your SRAM buffer, and
the memory address must point to the buffer originally used for "classic"
DMA operation. Use the previous (struct dma_slave_config).peripheral_size
and .peripheral_config that have been updated by STM32 DMA driver, to set
(struct dma_slave_config).peripheral_size and .peripheral_config of the
struct dma_slave_config to configure STM32 MDMA channel.
::
struct dma_slave_config dma_conf;
struct dma_slave_config mdma_conf;
memset(&dma_conf, 0, sizeof(dma_conf));
[...]
config.direction = DMA_DEV_TO_MEM;
config.dst_addr = sram_dma_buf; // SRAM buffer
config.peripheral_size = 1; // peripheral_size != 0 => chaining
dmaengine_slave_config(dma_chan, &dma_config);
memset(&mdma_conf, 0, sizeof(mdma_conf));
config.direction = DMA_DEV_TO_MEM;
mdma_conf.src_addr = sram_dma_buf; // SRAM buffer
mdma_conf.dst_addr = rx_dma_buf; // original memory buffer
mdma_conf.peripheral_size = dma_conf.peripheral_size; // <- dma_conf
mdma_conf.peripheral_config = dma_config.peripheral_config; // <- dma_conf
dmaengine_slave_config(mdma_chan, &mdma_conf);
**2. Get a descriptor for STM32 DMA channel transaction**
In the same way you get your descriptor for your "classic" DMA operation,
you just have to replace the original sg_list (in case of
dmaengine_prep_slave_sg()) with the new sg_list using SRAM buffer, or to
replace the original buffer address, length and period (in case of
dmaengine_prep_dma_cyclic()) with the new SRAM buffer.
**3. Get a descriptor for STM32 MDMA channel transaction**
If you previously get descriptor (for STM32 DMA) with
* dmaengine_prep_slave_sg(), then use dmaengine_prep_slave_sg() for
STM32 MDMA;
* dmaengine_prep_dma_cyclic(), then use dmaengine_prep_dma_cyclic() for
STM32 MDMA.
Use the new sg_list using SRAM buffer (in case of dmaengine_prep_slave_sg())
or, depending on the transfer direction, either the original DDR buffer (in
case of DMA_DEV_TO_MEM) or the SRAM buffer (in case of DMA_MEM_TO_DEV), the
source address being previously set with dmaengine_slave_config().
**4. Submit both transactions**
Before submitting your transactions, you may need to define on which
descriptor you want a callback to be called at the end of the transfer
(dmaengine_prep_slave_sg()) or the period (dmaengine_prep_dma_cyclic()).
Depending on the direction, set the callback on the descriptor that finishes
the overall transfer:
* DMA_DEV_TO_MEM: set the callback on the "MDMA" descriptor
* DMA_MEM_TO_DEV: set the callback on the "DMA" descriptor
Then, submit the descriptors whatever the order, with dmaengine_tx_submit().
**5. Issue pending requests (and wait for callback notification)**
As STM32 MDMA channel transfer is triggered by STM32 DMA, you must issue
STM32 MDMA channel before STM32 DMA channel.
If any, your callback will be called to warn you about the end of the overall
transfer or the period completion.
Don't forget to terminate both channels. STM32 DMA channel is configured in
cyclic Double-Buffer mode so it won't be disabled by HW, you need to terminate
it. STM32 MDMA channel will be stopped by HW in case of sg transfer, but not
in case of cyclic transfer. You can terminate it whatever the kind of transfer.
**STM32 DMA-MDMA chaining DMA_MEM_TO_DEV special case**
STM32 DMA-MDMA chaining in DMA_MEM_TO_DEV is a special case. Indeed, the
STM32 MDMA feeds the SRAM buffer with the DDR data, and the STM32 DMA reads
data from SRAM buffer. So some data (the first period) have to be copied in
SRAM buffer when the STM32 DMA starts to read.
A trick could be pausing the STM32 DMA channel (that will raise a Transfer
Complete signal, triggering the STM32 MDMA channel), but the first data read
by the STM32 DMA could be "wrong". The proper way is to prepare the first SRAM
period with dmaengine_prep_dma_memcpy(). Then this first period should be
"removed" from the sg or the cyclic transfer.
Due to this complexity, rather use the STM32 DMA-MDMA chaining for
DMA_DEV_TO_MEM and keep the "classic" DMA usage for DMA_MEM_TO_DEV, unless
you're not afraid.
Resources
---------
Application note, datasheet and reference manual are available on ST website
(STM32MP1_).
Dedicated focus on three application notes (AN5224_, AN4031_ & AN5001_)
dealing with STM32 DMAMUX, STM32 DMA and STM32 MDMA.
.. _STM32MP1: https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html
.. _AN5224: https://www.st.com/resource/en/application_note/an5224-stm32-dmamux-the-dma-request-router-stmicroelectronics.pdf
.. _AN4031: https://www.st.com/resource/en/application_note/dm00046011-using-the-stm32f2-stm32f4-and-stm32f7-series-dma-controller-stmicroelectronics.pdf
.. _AN5001: https://www.st.com/resource/en/application_note/an5001-stm32cube-expansion-package-for-stm32h7-series-mdma-stmicroelectronics.pdf
:Authors:
- Amelie Delaunay <amelie.delaunay@foss.st.com>
linux-7.2.3/Documentation/arch/arm/stm32/stm32f429-overview.rst
+25
View File
@@ -0,0 +1,25 @@
==================
STM32F429 Overview
==================
Introduction
------------
The STM32F429 is a Cortex-M4 MCU aimed at various applications.
It features:
- ARM Cortex-M4 up to 180MHz with FPU
- 2MB internal Flash Memory
- External memory support through FMC controller (PSRAM, SDRAM, NOR, NAND)
- I2C, SPI, SAI, CAN, USB OTG, Ethernet controllers
- LCD controller & Camera interface
- Cryptographic processor
Resources
---------
Datasheet and reference manual are publicly available on ST website (STM32F429_).
.. _STM32F429: http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577/LN1806?ecmp=stm32f429-439_pron_pr-ces2014_nov2013
:Authors: Maxime Coquelin <mcoquelin.stm32@gmail.com>
linux-7.2.3/Documentation/arch/arm/stm32/stm32f746-overview.rst
+32
View File
@@ -0,0 +1,32 @@
==================
STM32F746 Overview
==================
Introduction
------------
The STM32F746 is a Cortex-M7 MCU aimed at various applications.
It features:
- Cortex-M7 core running up to @216MHz
- 1MB internal flash, 320KBytes internal RAM (+4KB of backup SRAM)
- FMC controller to connect SDRAM, NOR and NAND memories
- Dual mode QSPI
- SD/MMC/SDIO support
- Ethernet controller
- USB OTFG FS & HS controllers
- I2C, SPI, CAN buses support
- Several 16 & 32 bits general purpose timers
- Serial Audio interface
- LCD controller
- HDMI-CEC
- SPDIFRX
Resources
---------
Datasheet and reference manual are publicly available on ST website (STM32F746_).
.. _STM32F746: http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f7-series/stm32f7x6/stm32f746ng.html
:Authors: Alexandre Torgue <alexandre.torgue@st.com>
linux-7.2.3/Documentation/arch/arm/stm32/stm32f769-overview.rst
+34
View File
@@ -0,0 +1,34 @@
==================
STM32F769 Overview
==================
Introduction
------------
The STM32F769 is a Cortex-M7 MCU aimed at various applications.
It features:
- Cortex-M7 core running up to @216MHz
- 2MB internal flash, 512KBytes internal RAM (+4KB of backup SRAM)
- FMC controller to connect SDRAM, NOR and NAND memories
- Dual mode QSPI
- SD/MMC/SDIO support*2
- Ethernet controller
- USB OTFG FS & HS controllers
- I2C*4, SPI*6, CAN*3 buses support
- Several 16 & 32 bits general purpose timers
- Serial Audio interface*2
- LCD controller
- HDMI-CEC
- DSI
- SPDIFRX
- MDIO salave interface
Resources
---------
Datasheet and reference manual are publicly available on ST website (STM32F769_).
.. _STM32F769: http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32-high-performance-mcus/stm32f7-series/stm32f7x9/stm32f769ni.html
:Authors: Alexandre Torgue <alexandre.torgue@st.com>
linux-7.2.3/Documentation/arch/arm/stm32/stm32h743-overview.rst
+33
View File
@@ -0,0 +1,33 @@
==================
STM32H743 Overview
==================
Introduction
------------
The STM32H743 is a Cortex-M7 MCU aimed at various applications.
It features:
- Cortex-M7 core running up to @400MHz
- 2MB internal flash, 1MBytes internal RAM
- FMC controller to connect SDRAM, NOR and NAND memories
- Dual mode QSPI
- SD/MMC/SDIO support
- Ethernet controller
- USB OTFG FS & HS controllers
- I2C, SPI, CAN buses support
- Several 16 & 32 bits general purpose timers
- Serial Audio interface
- LCD controller
- HDMI-CEC
- SPDIFRX
- DFSDM
Resources
---------
Datasheet and reference manual are publicly available on ST website (STM32H743_).
.. _STM32H743: http://www.st.com/en/microcontrollers/stm32h7x3.html?querycriteria=productId=LN2033
:Authors: Alexandre Torgue <alexandre.torgue@st.com>
linux-7.2.3/Documentation/arch/arm/stm32/stm32h750-overview.rst
+34
View File
@@ -0,0 +1,34 @@
==================
STM32H750 Overview
==================
Introduction
------------
The STM32H750 is a Cortex-M7 MCU aimed at various applications.
It features:
- Cortex-M7 core running up to @480MHz
- 128K internal flash, 1MBytes internal RAM
- FMC controller to connect SDRAM, NOR and NAND memories
- Dual mode QSPI
- SD/MMC/SDIO support
- Ethernet controller
- USB OTFG FS & HS controllers
- I2C, SPI, CAN buses support
- Several 16 & 32 bits general purpose timers
- Serial Audio interface
- LCD controller
- HDMI-CEC
- SPDIFRX
- DFSDM
Resources
---------
Datasheet and reference manual are publicly available on ST website (STM32H750_).
.. _STM32H750: https://www.st.com/en/microcontrollers-microprocessors/stm32h750-value-line.html
:Authors: Dillon Min <dillon.minfei@gmail.com>
linux-7.2.3/Documentation/arch/arm/stm32/stm32mp13-overview.rst
+37
View File
@@ -0,0 +1,37 @@
===================
STM32MP13 Overview
===================
Introduction
------------
The STM32MP131/STM32MP133/STM32MP135 are Cortex-A MPU aimed at various applications.
They feature:
- One Cortex-A7 application core
- Standard memories interface support
- Standard connectivity, widely inherited from the STM32 MCU family
- Comprehensive security support
More details:
- Cortex-A7 core running up to @900MHz
- FMC controller to connect SDRAM, NOR and NAND memories
- QSPI
- SD/MMC/SDIO support
- 2*Ethernet controller
- CAN
- ADC/DAC
- USB EHCI/OHCI controllers
- USB OTG
- I2C, SPI, CAN buses support
- Several general purpose timers
- Serial Audio interface
- LCD controller
- DCMIPP
- SPDIFRX
- DFSDM
:Authors:
- Alexandre Torgue <alexandre.torgue@foss.st.com>
linux-7.2.3/Documentation/arch/arm/stm32/stm32mp151-overview.rst
+36
View File
@@ -0,0 +1,36 @@
===================
STM32MP151 Overview
===================
Introduction
------------
The STM32MP151 is a Cortex-A MPU aimed at various applications.
It features:
- Single Cortex-A7 application core
- Standard memories interface support
- Standard connectivity, widely inherited from the STM32 MCU family
- Comprehensive security support
More details:
- Cortex-A7 core running up to @800MHz
- FMC controller to connect SDRAM, NOR and NAND memories
- QSPI
- SD/MMC/SDIO support
- Ethernet controller
- ADC/DAC
- USB EHCI/OHCI controllers
- USB OTG
- I2C, SPI buses support
- Several general purpose timers
- Serial Audio interface
- LCD-TFT controller
- DCMIPP
- SPDIFRX
- DFSDM
:Authors:
- Roan van Dijk <roan@protonic.nl>
linux-7.2.3/Documentation/arch/arm/stm32/stm32mp157-overview.rst
+20
View File
@@ -0,0 +1,20 @@
===================
STM32MP157 Overview
===================
Introduction
------------
The STM32MP157 is a Cortex-A MPU aimed at various applications.
It features:
- Dual core Cortex-A7 application core
- 2D/3D image composition with GPU
- Standard memories interface support
- Standard connectivity, widely inherited from the STM32 MCU family
- Comprehensive security support
:Authors:
- Ludovic Barre <ludovic.barre@st.com>
- Gerald Baeza <gerald.baeza@st.com>
linux-7.2.3/Documentation/arch/arm/sunxi.rst
+170
View File
@@ -0,0 +1,170 @@
==================
ARM Allwinner SoCs
==================
This document lists all the ARM Allwinner SoCs that are currently
supported in mainline by the Linux kernel. This document will also
provide links to documentation and/or datasheet for these SoCs.
SunXi family
------------
Linux kernel mach directory: arch/arm/mach-sunxi
Flavors:
* ARM926 based SoCs
- Allwinner F20 (sun3i)
* Not Supported
* ARM Cortex-A8 based SoCs
- Allwinner A10 (sun4i)
* Datasheet
http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf
* User Manual
http://dl.linux-sunxi.org/A10/A10%20User%20Manual%20-%20v1.20%20%282012-04-09%2c%20DECRYPTED%29.pdf
- Allwinner A10s (sun5i)
* Datasheet
http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf
- Allwinner A13 / R8 (sun5i)
* Datasheet
http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
* User Manual
http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-01-08%29.pdf
- Next Thing Co GR8 (sun5i)
* Single ARM Cortex-A7 based SoCs
- Allwinner V3s (sun8i)
* Datasheet
http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
* Dual ARM Cortex-A7 based SoCs
- Allwinner A20 (sun7i)
* User Manual
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
- Allwinner A23 (sun8i)
* Datasheet
http://dl.linux-sunxi.org/A23/A23%20Datasheet%20V1.0%2020130830.pdf
* User Manual
http://dl.linux-sunxi.org/A23/A23%20User%20Manual%20V1.0%2020130830.pdf
* Quad ARM Cortex-A7 based SoCs
- Allwinner A31 (sun6i)
* Datasheet
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20datasheet%20V1.3%2020131106.pdf
* User Manual
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20user%20manual%20V1.1%2020130630.pdf
- Allwinner A31s (sun6i)
* Datasheet
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20datasheet%20V1.3%2020131106.pdf
* User Manual
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20User%20Manual%20%20V1.0%2020130322.pdf
- Allwinner A33 (sun8i)
* Datasheet
http://dl.linux-sunxi.org/A33/A33%20Datasheet%20release%201.1.pdf
* User Manual
http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf
- Allwinner H2+ (sun8i)
* No document available now, but is known to be working properly with
H3 drivers and memory map.
- Allwinner H3 (sun8i)
* Datasheet
https://linux-sunxi.org/images/4/4b/Allwinner_H3_Datasheet_V1.2.pdf
- Allwinner R40 (sun8i)
* Datasheet
https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf
* User Manual
https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
- Allwinner A80
* Datasheet
http://dl.linux-sunxi.org/A80/A80_Datasheet_Revision_1.0_0404.pdf
* Octa ARM Cortex-A7 based SoCs
- Allwinner A83T
* Datasheet
https://github.com/allwinner-zh/documents/raw/master/A83T/A83T_Datasheet_v1.3_20150510.pdf
* User Manual
https://github.com/allwinner-zh/documents/raw/master/A83T/A83T_User_Manual_v1.5.1_20150513.pdf
* Quad ARM Cortex-A53 based SoCs
- Allwinner A64
* Datasheet
http://dl.linux-sunxi.org/A64/A64_Datasheet_V1.1.pdf
* User Manual
http://dl.linux-sunxi.org/A64/Allwinner%20A64%20User%20Manual%20v1.0.pdf
- Allwinner H6
* Datasheet
https://linux-sunxi.org/images/5/5c/Allwinner_H6_V200_Datasheet_V1.1.pdf
* User Manual
https://linux-sunxi.org/images/4/46/Allwinner_H6_V200_User_Manual_V1.1.pdf
- Allwinner H616
* Datasheet
https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf
* User Manual
https://linux-sunxi.org/images/2/24/H616_User_Manual_V1.0_cleaned.pdf
linux-7.2.3/Documentation/arch/arm/sunxi/clocks.rst
+57
View File
@@ -0,0 +1,57 @@
=======================================================
Frequently asked questions about the sunxi clock system
=======================================================
This document contains useful bits of information that people tend to ask
about the sunxi clock system, as well as accompanying ASCII art when adequate.
Q: Why is the main 24MHz oscillator gateable? Wouldn't that break the
system?
A: The 24MHz oscillator allows gating to save power. Indeed, if gated
carelessly the system would stop functioning, but with the right
steps, one can gate it and keep the system running. Consider this
simplified suspend example:
While the system is operational, you would see something like::
24MHz 32kHz
|
PLL1
\
\_ CPU Mux
|
[CPU]
When you are about to suspend, you switch the CPU Mux to the 32kHz
oscillator::
24Mhz 32kHz
| |
PLL1 |
/
CPU Mux _/
|
[CPU]
Finally you can gate the main oscillator::
32kHz
|
|
/
CPU Mux _/
|
[CPU]
Q: Were can I learn more about the sunxi clocks?
A: The linux-sunxi wiki contains a page documenting the clock registers,
you can find it at
http://linux-sunxi.org/A10/CCM
The authoritative source for information at this time is the ccmu driver
released by Allwinner, you can find it at
https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.0/arch/arm/mach-sun4i/clock/ccmu
linux-7.2.3/Documentation/arch/arm/swp_emulation.rst
+27
View File
@@ -0,0 +1,27 @@
Software emulation of deprecated SWP instruction (CONFIG_SWP_EMULATE)
---------------------------------------------------------------------
ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommends
moving to the load-locked/store-conditional instructions LDREX and STREX.
ARMv7 multiprocessing extensions introduce the ability to disable these
instructions, triggering an undefined instruction exception when executed.
Trapped instructions are emulated using an LDREX/STREX or LDREXB/STREXB
sequence. If a memory access fault (an abort) occurs, a segmentation fault is
signalled to the triggering process.
/proc/cpu/swp_emulation holds some statistics/information, including the PID of
the last process to trigger the emulation to be invocated. For example::
Emulated SWP: 12
Emulated SWPB: 0
Aborted SWP{B}: 1
Last process: 314
NOTE:
when accessing uncached shared regions, LDREX/STREX rely on an external
transaction monitoring block called a global monitor to maintain update
atomicity. If your system does not implement a global monitor, this option can
cause programs that perform SWP operations to uncached memory to deadlock, as
the STREX operation will always fail.
linux-7.2.3/Documentation/arch/arm/tcm.rst
+161
View File
@@ -0,0 +1,161 @@
==================================================
ARM TCM (Tightly-Coupled Memory) handling in Linux
==================================================
Written by Linus Walleij <linus.walleij@stericsson.com>
Some ARM SoCs have a so-called TCM (Tightly-Coupled Memory).
This is usually just a few (4-64) KiB of RAM inside the ARM
processor.
Due to being embedded inside the CPU, the TCM has a
Harvard-architecture, so there is an ITCM (instruction TCM)
and a DTCM (data TCM). The DTCM can not contain any
instructions, but the ITCM can actually contain data.
The size of DTCM or ITCM is minimum 4KiB so the typical
minimum configuration is 4KiB ITCM and 4KiB DTCM.
ARM CPUs have special registers to read out status, physical
location and size of TCM memories. arch/arm/include/asm/cputype.h
defines a CPUID_TCM register that you can read out from the
system control coprocessor. Documentation from ARM can be found
at http://infocenter.arm.com, search for "TCM Status Register"
to see documents for all CPUs. Reading this register you can
determine if ITCM (bits 1-0) and/or DTCM (bit 17-16) is present
in the machine.
There is further a TCM region register (search for "TCM Region
Registers" at the ARM site) that can report and modify the location
size of TCM memories at runtime. This is used to read out and modify
TCM location and size. Notice that this is not a MMU table: you
actually move the physical location of the TCM around. At the
place you put it, it will mask any underlying RAM from the
CPU so it is usually wise not to overlap any physical RAM with
the TCM.
The TCM memory can then be remapped to another address again using
the MMU, but notice that the TCM is often used in situations where
the MMU is turned off. To avoid confusion the current Linux
implementation will map the TCM 1 to 1 from physical to virtual
memory in the location specified by the kernel. Currently Linux
will map ITCM to 0xfffe0000 and on, and DTCM to 0xfffe8000 and
on, supporting a maximum of 32KiB of ITCM and 32KiB of DTCM.
Newer versions of the region registers also support dividing these
TCMs in two separate banks, so for example an 8KiB ITCM is divided
into two 4KiB banks with its own control registers. The idea is to
be able to lock and hide one of the banks for use by the secure
world (TrustZone).
TCM is used for a few things:
- FIQ and other interrupt handlers that need deterministic
timing and cannot wait for cache misses.
- Idle loops where all external RAM is set to self-refresh
retention mode, so only on-chip RAM is accessible by
the CPU and then we hang inside ITCM waiting for an
interrupt.
- Other operations which implies shutting off or reconfiguring
the external RAM controller.
There is an interface for using TCM on the ARM architecture
in <asm/tcm.h>. Using this interface it is possible to:
- Define the physical address and size of ITCM and DTCM.
- Tag functions to be compiled into ITCM.
- Tag data and constants to be allocated to DTCM and ITCM.
- Have the remaining TCM RAM added to a special
allocation pool with gen_pool_create() and gen_pool_add()
and provide tcm_alloc() and tcm_free() for this
memory. Such a heap is great for things like saving
device state when shutting off device power domains.
A machine that has TCM memory shall select HAVE_TCM from
arch/arm/Kconfig for itself. Code that needs to use TCM shall
#include <asm/tcm.h>
Functions to go into itcm can be tagged like this:
int __tcmfunc foo(int bar);
Since these are marked to become long_calls and you may want
to have functions called locally inside the TCM without
wasting space, there is also the __tcmlocalfunc prefix that
will make the call relative.
Variables to go into dtcm can be tagged like this::
int __tcmdata foo;
Constants can be tagged like this::
int __tcmconst foo;
To put assembler into TCM just use::
.section ".tcm.text" or .section ".tcm.data"
respectively.
Example code::
#include <asm/tcm.h>
/* Uninitialized data */
static u32 __tcmdata tcmvar;
/* Initialized data */
static u32 __tcmdata tcmassigned = 0x2BADBABEU;
/* Constant */
static const u32 __tcmconst tcmconst = 0xCAFEBABEU;
static void __tcmlocalfunc tcm_to_tcm(void)
{
int i;
for (i = 0; i < 100; i++)
tcmvar ++;
}
static void __tcmfunc hello_tcm(void)
{
/* Some abstract code that runs in ITCM */
int i;
for (i = 0; i < 100; i++) {
tcmvar ++;
}
tcm_to_tcm();
}
static void __init test_tcm(void)
{
u32 *tcmem;
int i;
hello_tcm();
printk("Hello TCM executed from ITCM RAM\n");
printk("TCM variable from testrun: %u @ %p\n", tcmvar, &tcmvar);
tcmvar = 0xDEADBEEFU;
printk("TCM variable: 0x%x @ %p\n", tcmvar, &tcmvar);
printk("TCM assigned variable: 0x%x @ %p\n", tcmassigned, &tcmassigned);
printk("TCM constant: 0x%x @ %p\n", tcmconst, &tcmconst);
/* Allocate some TCM memory from the pool */
tcmem = tcm_alloc(20);
if (tcmem) {
printk("TCM Allocated 20 bytes of TCM @ %p\n", tcmem);
tcmem[0] = 0xDEADBEEFU;
tcmem[1] = 0x2BADBABEU;
tcmem[2] = 0xCAFEBABEU;
tcmem[3] = 0xDEADBEEFU;
tcmem[4] = 0x2BADBABEU;
for (i = 0; i < 5; i++)
printk("TCM tcmem[%d] = %08x\n", i, tcmem[i]);
tcm_free(tcmem, 20);
}
}
linux-7.2.3/Documentation/arch/arm/uefi.rst
+72
View File
@@ -0,0 +1,72 @@
================================================
The Unified Extensible Firmware Interface (UEFI)
================================================
UEFI, the Unified Extensible Firmware Interface, is a specification
governing the behaviours of compatible firmware interfaces. It is
maintained by the UEFI Forum - http://www.uefi.org/.
UEFI is an evolution of its predecessor 'EFI', so the terms EFI and
UEFI are used somewhat interchangeably in this document and associated
source code. As a rule, anything new uses 'UEFI', whereas 'EFI' refers
to legacy code or specifications.
UEFI support in Linux
=====================
Booting on a platform with firmware compliant with the UEFI specification
makes it possible for the kernel to support additional features:
- UEFI Runtime Services
- Retrieving various configuration information through the standardised
interface of UEFI configuration tables. (ACPI, SMBIOS, ...)
For actually enabling [U]EFI support, enable:
- CONFIG_EFI=y
- CONFIG_EFIVAR_FS=y or m
The implementation depends on receiving information about the UEFI environment
in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF.
UEFI stub
=========
The "stub" is a feature that extends the Image/zImage into a valid UEFI
PE/COFF executable, including a loader application that makes it possible to
load the kernel directly from the UEFI shell, boot menu, or one of the
lightweight bootloaders like Gummiboot or rEFInd.
The kernel image built with stub support remains a valid kernel image for
booting in non-UEFI environments.
UEFI kernel support on ARM
==========================
UEFI kernel support on the ARM architectures (arm and arm64) is only available
when boot is performed through the stub.
When booting in UEFI mode, the stub deletes any memory nodes from a provided DT.
Instead, the kernel reads the UEFI memory map.
The stub populates the FDT /chosen node with (and the kernel scans for) the
following parameters:
========================== ====== ===========================================
Name Type Description
========================== ====== ===========================================
linux,uefi-system-table 64-bit Physical address of the UEFI System Table.
linux,uefi-mmap-start 64-bit Physical address of the UEFI memory map,
populated by the UEFI GetMemoryMap() call.
linux,uefi-mmap-size 32-bit Size in bytes of the UEFI memory map
pointed to in previous entry.
linux,uefi-mmap-desc-size 32-bit Size in bytes of each entry in the UEFI
memory map.
linux,uefi-mmap-desc-ver 32-bit Version of the mmap descriptor format.
kaslr-seed 64-bit Entropy used to randomize the kernel image
base address location.
bootargs String Kernel command line
========================== ====== ===========================================
linux-7.2.3/Documentation/arch/arm/vfp/release-notes.rst
+57
View File
@@ -0,0 +1,57 @@
===============================================
Release notes for Linux Kernel VFP support code
===============================================
Date: 20 May 2004
Author: Russell King
This is the first release of the Linux Kernel VFP support code. It
provides support for the exceptions bounced from VFP hardware found
on ARM926EJ-S.
This release has been validated against the SoftFloat-2b library by
John R. Hauser using the TestFloat-2a test suite. Details of this
library and test suite can be found at:
http://www.jhauser.us/arithmetic/SoftFloat.html
The operations which have been tested with this package are:
- fdiv
- fsub
- fadd
- fmul
- fcmp
- fcmpe
- fcvtd
- fcvts
- fsito
- ftosi
- fsqrt
All the above pass softfloat tests with the following exceptions:
- fadd/fsub shows some differences in the handling of +0 / -0 results
when input operands differ in signs.
- the handling of underflow exceptions is slightly different. If a
result underflows before rounding, but becomes a normalised number
after rounding, we do not signal an underflow exception.
Other operations which have been tested by basic assembly-only tests
are:
- fcpy
- fabs
- fneg
- ftoui
- ftosiz
- ftouiz
The combination operations have not been tested:
- fmac
- fnmac
- fmsc
- fnmsc
- fnmul
linux-7.2.3/Documentation/arch/arm/vlocks.rst
+212
View File
@@ -0,0 +1,212 @@
======================================
vlocks for Bare-Metal Mutual Exclusion
======================================
Voting Locks, or "vlocks" provide a simple low-level mutual exclusion
mechanism, with reasonable but minimal requirements on the memory
system.
These are intended to be used to coordinate critical activity among CPUs
which are otherwise non-coherent, in situations where the hardware
provides no other mechanism to support this and ordinary spinlocks
cannot be used.
vlocks make use of the atomicity provided by the memory system for
writes to a single memory location. To arbitrate, every CPU "votes for
itself", by storing a unique number to a common memory location. The
final value seen in that memory location when all the votes have been
cast identifies the winner.
In order to make sure that the election produces an unambiguous result
in finite time, a CPU will only enter the election in the first place if
no winner has been chosen and the election does not appear to have
started yet.
Algorithm
---------
The easiest way to explain the vlocks algorithm is with some pseudo-code::
int currently_voting[NR_CPUS] = { 0, };
int last_vote = -1; /* no votes yet */
bool vlock_trylock(int this_cpu)
{
/* signal our desire to vote */
currently_voting[this_cpu] = 1;
if (last_vote != -1) {
/* someone already volunteered himself */
currently_voting[this_cpu] = 0;
return false; /* not ourself */
}
/* let's suggest ourself */
last_vote = this_cpu;
currently_voting[this_cpu] = 0;
/* then wait until everyone else is done voting */
for_each_cpu(i) {
while (currently_voting[i] != 0)
/* wait */;
}
/* result */
if (last_vote == this_cpu)
return true; /* we won */
return false;
}
bool vlock_unlock(void)
{
last_vote = -1;
}
The currently_voting[] array provides a way for the CPUs to determine
whether an election is in progress, and plays a role analogous to the
"entering" array in Lamport's bakery algorithm [1].
However, once the election has started, the underlying memory system
atomicity is used to pick the winner. This avoids the need for a static
priority rule to act as a tie-breaker, or any counters which could
overflow.
As long as the last_vote variable is globally visible to all CPUs, it
will contain only one value that won't change once every CPU has cleared
its currently_voting flag.
Features and limitations
------------------------
* vlocks are not intended to be fair. In the contended case, it is the
_last_ CPU which attempts to get the lock which will be most likely
to win.
vlocks are therefore best suited to situations where it is necessary
to pick a unique winner, but it does not matter which CPU actually
wins.
* Like other similar mechanisms, vlocks will not scale well to a large
number of CPUs.
vlocks can be cascaded in a voting hierarchy to permit better scaling
if necessary, as in the following hypothetical example for 4096 CPUs::
/* first level: local election */
my_town = towns[(this_cpu >> 4) & 0xf];
I_won = vlock_trylock(my_town, this_cpu & 0xf);
if (I_won) {
/* we won the town election, let's go for the state */
my_state = states[(this_cpu >> 8) & 0xf];
I_won = vlock_lock(my_state, this_cpu & 0xf);
if (I_won) {
/* and so on */
I_won = vlock_lock(the_whole_country, this_cpu & 0xf);
if (I_won) {
/* ... */
}
vlock_unlock(the_whole_country);
}
vlock_unlock(my_state);
}
vlock_unlock(my_town);
ARM implementation
------------------
The current ARM implementation [2] contains some optimisations beyond
the basic algorithm:
* By packing the members of the currently_voting array close together,
we can read the whole array in one transaction (providing the number
of CPUs potentially contending the lock is small enough). This
reduces the number of round-trips required to external memory.
In the ARM implementation, this means that we can use a single load
and comparison::
LDR Rt, [Rn]
CMP Rt, #0
...in place of code equivalent to::
LDRB Rt, [Rn]
CMP Rt, #0
LDRBEQ Rt, [Rn, #1]
CMPEQ Rt, #0
LDRBEQ Rt, [Rn, #2]
CMPEQ Rt, #0
LDRBEQ Rt, [Rn, #3]
CMPEQ Rt, #0
This cuts down on the fast-path latency, as well as potentially
reducing bus contention in contended cases.
The optimisation relies on the fact that the ARM memory system
guarantees coherency between overlapping memory accesses of
different sizes, similarly to many other architectures. Note that
we do not care which element of currently_voting appears in which
bits of Rt, so there is no need to worry about endianness in this
optimisation.
If there are too many CPUs to read the currently_voting array in
one transaction then multiple transactions are still required. The
implementation uses a simple loop of word-sized loads for this
case. The number of transactions is still fewer than would be
required if bytes were loaded individually.
In principle, we could aggregate further by using LDRD or LDM, but
to keep the code simple this was not attempted in the initial
implementation.
* vlocks are currently only used to coordinate between CPUs which are
unable to enable their caches yet. This means that the
implementation removes many of the barriers which would be required
when executing the algorithm in cached memory.
packing of the currently_voting array does not work with cached
memory unless all CPUs contending the lock are cache-coherent, due
to cache writebacks from one CPU clobbering values written by other
CPUs. (Though if all the CPUs are cache-coherent, you should be
probably be using proper spinlocks instead anyway).
* The "no votes yet" value used for the last_vote variable is 0 (not
-1 as in the pseudocode). This allows statically-allocated vlocks
to be implicitly initialised to an unlocked state simply by putting
them in .bss.
An offset is added to each CPU's ID for the purpose of setting this
variable, so that no CPU uses the value 0 for its ID.
Colophon
--------
Originally created and documented by Dave Martin for Linaro Limited, for
use in ARM-based big.LITTLE platforms, with review and input gratefully
received from Nicolas Pitre and Achin Gupta. Thanks to Nicolas for
grabbing most of this text out of the relevant mail thread and writing
up the pseudocode.
Copyright (C) 2012-2013 Linaro Limited
Distributed under the terms of Version 2 of the GNU General Public
License, as defined in linux/COPYING.
References
----------
[1] Lamport, L. "A New Solution of Dijkstra's Concurrent Programming
Problem", Communications of the ACM 17, 8 (August 1974), 453-455.
https://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm
[2] linux/arch/arm/common/vlock.S, www.kernel.org.
linux-7.2.3/Documentation/arch/arm/zte/index.rst
+10
View File
@@ -0,0 +1,10 @@
.. SPDX-License-Identifier: GPL-2.0-only
=======
ZTE SoC
=======
.. toctree::
:maxdepth: 1
zx297520v3
linux-7.2.3/Documentation/arch/arm/zte/zx297520v3.rst
+166
View File
@@ -0,0 +1,166 @@
.. SPDX-License-Identifier: GPL-2.0-only
====================================
Booting Linux on ZTE zx297520v3 SoCs
====================================
Author: Stefan Dösinger
Date : 27 Jan 2026
1. Hardware description
---------------------------
Zx297520v3 SoCs use a 64-bit capable Cortex-A53 CPU and GICv3, although they
run in arm32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
it seems to lack VFP and NEON.
The SoC is used in a number of cheap LTE to WiFi routers, both battery powered
MiFis and stationary CPEs. In addition to the CPU these devices usually have
64 MB Ram (although some is shared with the LTE chip), 128 MB NAND flash, an
SDIO connected RTL8192-type Wifi chip limited to 2.4 ghz operation, USB 2,
and buttons. Devices with as low as 32 MB or as high as 128 MB ram exist, as
do devices with 8 or 16 MB of NOR flash.
Some devices, especially the stationary ones, have 100 mbit Ethernet and an
Ethernet switch.
Usually the devices have LEDs for status indication, although some have SPI or
I2C connected displays.
Some have an SD card slot. If it exists, it is a better choice for the root
file system because it easily outperforms the built-in NAND.
The LTE interface runs on a separate DSP called ZSP880. It is probably derived
from LSI ZSPs and has an undocumented instruction set. The ZSP communicates
with the main CPU via SRAM and DRAM and a mailbox hardware that can generate
IRQs on either ends.
There is also a Cortex M0 CPU, which is responsible for early HW initialization
and starting the Cortex A53 CPU. It does not have any essential purpose once
U-Boot is started. An SRAM-based handover protocol exists to run custom code on
this CPU.
2. Booting via USB
---------------------------
The Boot ROM has support for booting custom code via USB. This mode can be
entered by connecting a Boot PIN to GND or by modifying the third byte on NAND
(set it to anything other than 0x5A aka 'Z'). A free software tool to start
custom U-Boot and kernels can be found here:
https://github.com/zx297520v3-mainline/zx297520v3-loader
If USB download mode is entered but no boot commands are sent through USB, the
device will proceed to boot normally after a few seconds. It is therefore
possible to enable USB boot permanently and still leave the default boot files
in place.
https://github.com/zx297520v3-mainline/u-boot-mainline
Contains an U-Boot version that can be used with the USB loader and sets up the
CPU and interrupt controller to comply with Linux's booting requirements.
3. Building for built-in U-Boot
-------------------------------
The devices come with an ancient U-Boot that loads legacy uImages from NAND and
boots them without a chance for the user to interrupt. The images are stored in
files ap_cpuap.bin and ap_recovery.bin on a jffs2 partition named imagefs,
usually mtd4. A file named "fotaflag" switches between the two modes.
In addition to the uImage header, those files have a 384-byte signature header,
which is used for authenticating the images on some devices. Most devices have
this authentication disabled and it is enough to pad the uImage files with 384
zero bytes.
Builtin U-Boot also poorly sets up the CPU. Read the next section for details
on this. It has no support for loading DTBs, so CONFIG_ARM_APPENDED_DTB is
needed.
So to build an image that boots from NAND the following steps are necessary:
1) Patch the assembly code from section 3 into arch/arm/kernel/head.S.
2) make zx29_defconfig
3) make [-j x]
4) cat arch/arm/boot/zImage arch/arm/boot/dts/zte/[device].dtb > kernel+dtb
5) mkimage -A arm -O linux -T kernel -C none -a 0x20008000 -d kernel+dtb uimg
6) dd if=/dev/zero bs=1 count=384 of=ap_recovery.bin
7) cat uimg >> ap_recovery.bin
8) Place this file onto imagefs on the device. Delete ap_cpuap.bin if the
free space is not enough.
9) Create the file fotaflag: echo -n FOTA-RECOVERY > fotaflag
For development, booting ap_recovery.bin is recommended because the normal boot
mode arms the watchdog before starting the kernel.
4. CPU and GIC Setup
---------------------------
Generally CPU and GICv3 need to be set up according to the requirements spelled
out in Documentation/arch/arm64/booting.rst. For zx297520v3 this means:
1. GICD_CTLR.DS=1 to disable GIC security
2. Enable access to ICC_SRE
3. Disable trapping IRQs into monitor mode
4. Configure EL2 and below to run in insecure mode.
5. Configure timer PPIs to active-low.
The kernel sources provided by ZTE do not boot either (interrupts do not work
at all). They are incomplete in other aspects too, so it is assumed that there
is some workaround similar to the one described in this document somewhere in
the binary blobs.
The assembly code below is given as an example of how to achieve this:
::
#include <linux/irqchip/arm-gic-v3.h>
#include <asm/assembler.h>
#include <asm/cp15.h>
@ Detect sane bootloaders and skip the hack
ldr r3, =0xf2000000
ldr r3, [r3]
ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
cmp r3, r4
beq skip_zx_hack
@ This allows EL1 to handle ints hat are normally handled by EL2/3.
ldr r3, =0xf2000000
str r4, [r3]
cps #MON_MODE
@ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
@ seems to respond only to non-secure addresses. I have taken insipiration from
@ Raspberry pi's armstub7.S here.
mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
@ Allow hypervisor call.
mcr p15, 0, r3, c1, c1, 0
@ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
ldr r3, =0xF22020a8
ldr r4, =0x50
str r4, [r3]
ldr r3, =0xF22020ac
ldr r4, =0x14
str r4, [r3]
@ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
@ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
mcr p15, 6, r3, c12, c12, 5
mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
orr r3, #(ICC_SRE_EL1_SRE)
mcr p15, 0, r3, c12, c12, 5
@ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
@ for EL2.
mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
mcr p15, 4, r3, c12, c9, 5
isb
@ Back to SVC mode
cps #SVC_MODE
skip_zx_hack: