ukui/kernel
0
0
Fork 0
mirror of https://github.com/ukui/kernel.git synced 2026-03-09 10:07:04 -07:00
Code Issues Packages Projects Releases Wiki Activity

docs: arm: convert docs to ReST and rename to *.rst

Browse Source 
Converts ARM the text files to ReST, preparing them to be an
architecture book.

The conversion is actually:
  - add blank lines and identation in order to identify paragraphs;
  - fix tables markups;
  - add some lists markups;
  - mark literal blocks;
  - adjust title markups.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Reviewed-by Corentin Labbe <clabbe.montjoie@gmail.com> # For sun4i-ss
This commit is contained in:
Mauro Carvalho Chehab
2019-04-14 15:51:10 -03:00
parent 0d07cf5e53
commit dc7a12bdfc
115 changed files with 1985 additions and 1420 deletions
Download Patch File Download Diff File Expand all files Collapse all files

395
Documentation/arm/Marvell/README
View File

@@ -1,395 +0,0 @@
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
88F5181L
88F5182
Datasheet : http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf
Programmer's User Guide : http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf
User Manual : http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf
88F5281
Datasheet : http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
88F6183
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 : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
88F6283 a.k.a Armada 310
Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
88F6190
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
88F6192
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
88F6182
88F6180
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
88F6281
Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
Homepage: 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 : http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78100-003_WEB.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78100_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
MV78200
Product Brief : http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78200-002_WEB.pdf
Hardware Spec : http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78200_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
MV76100
Not supported by the Linux kernel.
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 Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
Hardware Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
Core: Sheeva ARMv7 compatible PJ4B
Armada 375 Flavors:
88F6720
Product Brief: 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
88F6820 Armada 385
88F6828 Armada 388
Product infos: http://www.marvell.com/embedded-processors/armada-38x/
Functional Spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/
Core: ARM Cortex-A9
Armada 39x Flavors:
88F6920 Armada 390
88F6928 Armada 398
Product infos: http://www.marvell.com/embedded-processors/armada-39x/
Core: ARM Cortex-A9
Armada XP Flavors:
MV78230
MV78260
MV78460
NOTE: not to be confused with the non-SMP 78xx0 SoCs
Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
Functional Spec: http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
Hardware Specs:
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
Core: Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP
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: http://www.marvell.com/embedded-processors/armada-3700/
Product Brief: http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
Device tree files: arch/arm64/boot/dts/marvell/armada-37*
Armada 7K Flavors:
88F7020 (AP806 Dual + one CP110)
88F7040 (AP806 Quad + one CP110)
Core: ARM Cortex A72
Homepage: http://www.marvell.com/embedded-processors/armada-70xx/
Product Brief: http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf
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: http://www.marvell.com/embedded-processors/armada-80xx/
Product Brief: http://www.marvell.com/embedded-processors/assets/Armada8020PB-Jan2016.pdf
http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf
Device tree files: arch/arm64/boot/dts/marvell/armada-80*
Avanta family
-------------
Flavors:
88F6510
88F6530P
88F6550
88F6560
Homepage : http://www.marvell.com/broadband/
Product Brief: 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: http://www.marvell.com/storage/armada-sp/
Core: Sheeva ARMv7 comatible Quad-core PJ4C
(not supported in upstream Linux kernel)
Dove family (application processor)
-----------------------------------
Flavors:
88AP510 a.k.a Armada 510
Product Brief : http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf
Hardware Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Hardware-Spec.pdf
Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
Homepage: 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 : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
Developers manual : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_dev_man.pdf
Specification : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
Specification update : 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 : http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
PXA 310 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
PXA 320 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA320_PB_R4.pdf
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Design_Guide.pdf
Developers manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip
Specifications : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_EMTS.pdf
Specification Update : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
Reference Manual : 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
Linux kernel plat directory: arch/arm/plat-pxa
MMP/MMP2/MMP3 family (communication processor)
-----------------------------------------
Flavors:
PXA168, a.k.a Armada 168
Homepage : http://www.marvell.com/application-processors/armada-100/armada-168.jsp
Product brief : http://www.marvell.com/application-processors/armada-100/assets/pxa_168_pb.pdf
Hardware manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_datasheet.pdf
Software manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_software_manual.pdf
Specification update : http://www.marvell.com/application-processors/armada-100/assets/ARMADA16x_Spec_update.pdf
Boot ROM manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
App node package : 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 : http://www.marvell.com/communication-processors/pxa910/
Product Brief : http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf
Application processor with Communication processor
Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
PXA688, a.k.a. MMP2, a.k.a Armada 610
Product Brief : 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 (OLPC XO4, Linux support not upstream)
Product Brief : 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
Linux kernel plat directory: arch/arm/plat-pxa
Berlin family (Multimedia Solutions)
-------------------------------------
Flavors:
88DE3010, Armada 1000 (no Linux support)
Core: Marvell PJ1 (ARMv5TE), Dual-core
Product Brief: http://www.marvell.com.cn/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.
* Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
directory. The plat-pxa/ 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>

78
Documentation/arm/Netwinder
View File

@@ -1,78 +0,0 @@
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

21
Documentation/arm/SA1100/FreeBird
View File

@@ -1,21 +0,0 @@
Freebird-1.1 is produced by Legend(C), Inc.
http://web.archive.org/web/*/http://www.legend.com.cn
and software/linux maintained by Coventive(C), Inc.
(http://www.coventive.com)
Based on the Nicolas's strongarm kernel tree.
===============================================================
Maintainer:
Chester Kuo <chester@coventive.com>
<chester@linux.org.tw>
Author :
Tim wu <timwu@coventive.com>
CIH <cih@coventive.com>
Eric Peng <ericpeng@coventive.com>
Jeff Lee <jeff_lee@coventive.com>
Allen Cheng
Tony Liu <tonyliu@coventive.com>

2
Documentation/arm/SA1100/empeg
View File

@@ -1,2 +0,0 @@
See ../empeg/README

47
Documentation/arm/SA1100/serial_UART
View File

@@ -1,47 +0,0 @@
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.

50
Documentation/arm/README → Documentation/arm/arm.rst
View File

@@ -1,5 +1,6 @@
ARM Linux 2.6
=============
=======================
ARM Linux 2.6 and upper
=======================
Please check <ftp://ftp.arm.linux.org.uk/pub/armlinux> for
updates.
@@ -18,22 +19,28 @@ Compilation of kernel
line as detailed below.
If you wish to cross-compile, then alter the following lines in the top
level make file:
level make file::
ARCH = <whatever>
with
with::
ARCH = arm
and
and::
CROSS_COMPILE=
to
to::
CROSS_COMPILE=<your-path-to-your-compiler-without-gcc>
eg.
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
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'.
@@ -46,7 +53,7 @@ Bug reports etc
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/
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
@@ -60,11 +67,13 @@ Include files
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
============= ==========================================================
`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
@@ -129,7 +138,7 @@ ST506 hard drives
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
`*configure` harddrive set to 2). I've got an internal 20MB and a great
big external 5.25" FH 64MB drive (who could ever want more :-) ).
I've just got 240K/s off it (a dd with bs=128k); thats about half of what
@@ -149,13 +158,13 @@ ST506 hard drives
are welcome.
CONFIG_MACH_ and CONFIG_ARCH_
-----------------------------
`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,
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
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.
@@ -163,7 +172,7 @@ CONFIG_MACH_ and CONFIG_ARCH_
<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.
@@ -201,4 +210,5 @@ Kernel entry (head.S)
platform is DT-only, you do not need a registered machine type.
---
Russell King (15/03/2004)

71
Documentation/arm/Booting → Documentation/arm/booting.rst
View File

@@ -1,7 +1,9 @@
Booting ARM Linux
=================
=================
Booting ARM Linux
=================
Author: Russell King
Date : 18 May 2002
The following documentation is relevant to 2.4.18-rmk6 and beyond.
@@ -25,8 +27,10 @@ following:
1. Setup and initialise RAM
---------------------------
Existing boot loaders: MANDATORY
New boot loaders: MANDATORY
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
@@ -39,8 +43,10 @@ sees fit.)
2. Initialise one serial port
-----------------------------
Existing boot loaders: OPTIONAL, RECOMMENDED
New boot loaders: OPTIONAL, RECOMMENDED
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
@@ -57,8 +63,10 @@ serial format options as described in
3. Detect the machine type
--------------------------
Existing boot loaders: OPTIONAL
New boot loaders: MANDATORY except for DT-only platforms
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
@@ -74,8 +82,10 @@ 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
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
@@ -97,15 +107,15 @@ 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:
minimum tagged list should look::
+-----------+
base -> | ATAG_CORE | |
+-----------+ |
| ATAG_MEM | | increasing address
+-----------+ |
| ATAG_NONE | |
+-----------+ v
+-----------+
base -> | ATAG_CORE | |
+-----------+ |
| ATAG_MEM | | increasing address
+-----------+ |
| ATAG_NONE | |
+-----------+ v
The tagged list should be stored in system RAM.
@@ -134,8 +144,10 @@ A safe location is just above the 128MiB boundary from start of RAM.
5. Load initramfs.
------------------
Existing boot loaders: OPTIONAL
New boot loaders: OPTIONAL
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
@@ -149,8 +161,10 @@ recommended above.
6. Calling the kernel image
---------------------------
Existing boot loaders: MANDATORY
New boot loaders: MANDATORY
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,
@@ -174,12 +188,14 @@ In any case, the following conditions must be met:
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
- 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
@@ -195,8 +211,11 @@ In any case, the following conditions must be met:
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

177
Documentation/arm/cluster-pm-race-avoidance.txt → Documentation/arm/cluster-pm-race-avoidance.rst
View File

@@ -1,3 +1,4 @@
=========================================================
Cluster-wide Power-up/power-down race avoidance algorithm
=========================================================
@@ -46,10 +47,12 @@ Basic model
Each cluster and CPU is assigned a state, as follows:
DOWN
COMING_UP
UP
GOING_DOWN
- DOWN
- COMING_UP
- UP
- GOING_DOWN
::
+---------> UP ----------+
| v
@@ -60,18 +63,22 @@ Each cluster and CPU is assigned a state, as follows:
+--------- DOWN <--------+
DOWN: The CPU or cluster is not coherent, and is either powered off or
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.
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
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
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.
@@ -86,8 +93,8 @@ 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.
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
@@ -101,10 +108,12 @@ 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
- CPU_DOWN
- CPU_COMING_UP
- CPU_UP
- CPU_GOING_DOWN
::
cluster setup and
CPU setup complete policy decision
@@ -130,17 +139,17 @@ 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
Next state:
CPU_COMING_UP
Conditions:
none
Trigger events:
a) an explicit hardware power-up operation, resulting
from a policy decision on another CPU;
@@ -148,15 +157,17 @@ CPU_DOWN:
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.
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.
@@ -178,20 +189,25 @@ CPU_UP:
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
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)
Next state:
CPU_DOWN
Conditions:
local CPU teardown complete
Trigger events:
(spontaneous)
Cluster state
@@ -212,20 +228,20 @@ 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:
on the outbound side:
CLUSTER_DOWN
CLUSTER_UP
CLUSTER_GOING_DOWN
- 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
- INBOUND_NOT_COMING_UP
- INBOUND_COMING_UP
The different pairings of these states results in six possible
states for the cluster as a whole:
states for the cluster as a whole::
CLUSTER_UP
+==========> INBOUND_NOT_COMING_UP -------------+
@@ -284,11 +300,12 @@ reason, the cluster state is split into two parts:
CLUSTER_DOWN/INBOUND_NOT_COMING_UP:
Next state:
CLUSTER_DOWN/INBOUND_COMING_UP (inbound)
Conditions:
none
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;
@@ -306,9 +323,12 @@ CLUSTER_DOWN/INBOUND_COMING_UP:
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)
Next state:
CLUSTER_UP/INBOUND_COMING_UP (inbound)
Conditions:
cluster-level setup and hardware coherency complete
Trigger events:
(spontaneous)
CLUSTER_UP/INBOUND_COMING_UP:
@@ -321,9 +341,12 @@ CLUSTER_UP/INBOUND_COMING_UP:
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)
Next state:
CLUSTER_UP/INBOUND_NOT_COMING_UP (inbound)
Conditions:
none
Trigger events:
(spontaneous)
CLUSTER_UP/INBOUND_NOT_COMING_UP:
@@ -335,9 +358,12 @@ CLUSTER_UP/INBOUND_NOT_COMING_UP:
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
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:
@@ -359,13 +385,16 @@ CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP:
Next states:
CLUSTER_DOWN/INBOUND_NOT_COMING_UP (outbound)
Conditions: cluster torn down and ready to power off
Trigger events: (spontaneous)
Conditions:
cluster torn down and ready to power off
Trigger events:
(spontaneous)
CLUSTER_GOING_DOWN/INBOUND_COMING_UP (inbound)
Conditions: none
Trigger events:
Conditions:
none
Trigger events:
a) an explicit hardware power-up operation,
resulting from a policy decision on another
CPU;
@@ -396,13 +425,19 @@ CLUSTER_GOING_DOWN/INBOUND_COMING_UP:
Next states:
CLUSTER_UP/INBOUND_COMING_UP (outbound)
Conditions: cluster-level setup and hardware
Conditions:
cluster-level setup and hardware
coherency complete
Trigger events: (spontaneous)
Trigger events:
(spontaneous)
CLUSTER_DOWN/INBOUND_COMING_UP (outbound)
Conditions: cluster torn down and ready to power off
Trigger events: (spontaneous)
Conditions:
cluster torn down and ready to power off
Trigger events:
(spontaneous)
Last man and First man selection
@@ -452,30 +487,30 @@ Implementation:
arch/arm/common/mcpm_entry.c (everything else):
__mcpm_cpu_going_down() signals the transition of a CPU to the
CPU_GOING_DOWN state.
CPU_GOING_DOWN state.
__mcpm_cpu_down() signals the transition of a CPU to the CPU_DOWN
state.
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.
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).
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.
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.
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:

14
Documentation/arm/firmware.txt → Documentation/arm/firmware.rst
View File

@@ -1,5 +1,7 @@
Interface for registering and calling firmware-specific operations for ARM.
----
==========================================================================
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
@@ -9,7 +11,7 @@ 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.
function::
void register_firmware_ops(const struct firmware_ops *ops)
@@ -19,7 +21,7 @@ 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
To call a firmware operation, a helper macro is provided::
#define call_firmware_op(op, ...) \
((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
@@ -28,7 +30,7 @@ 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:
Example of registering firmware operations::
/* board file */
@@ -56,7 +58,7 @@ Example of registering firmware operations:
register_firmware_ops(&platformX_firmware_ops);
}
Example of using a firmware operation:
Example of using a firmware operation::
/* some platform code, e.g. SMP initialization */

80
Documentation/arm/index.rst Normal file
View File

@@ -0,0 +1,80 @@
:orphan:
================
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
SoC-specific documents
======================
.. toctree::
:maxdepth: 1
ixp4xx
marvel
microchip
netwinder
nwfpe/index
keystone/overview
keystone/knav-qmss
omap/index
pxa/mfp
sa1100/index
stm32/stm32f746-overview
stm32/overview
stm32/stm32h743-overview
stm32/stm32f769-overview
stm32/stm32f429-overview
stm32/stm32mp157-overview
sunxi
samsung/index
samsung-s3c24xx/index
sunxi/clocks
spear/overview
sti/stih416-overview
sti/stih407-overview
sti/stih418-overview
sti/overview
sti/stih415-overview
vfp/release-notes
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

86
Documentation/arm/Interrupts → Documentation/arm/interrupts.rst
View File

@@ -1,8 +1,10 @@
2.5.2-rmk5
----------
==========
Interrupts
==========
This is the first kernel that contains a major shake up of some of the
major architecture-specific subsystems.
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 -
@@ -18,7 +20,7 @@ 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:
Lets take an example. On the Assabet with Neponset, we have::
GPIO25 IRR:2
SA1100 ------------> Neponset -----------> SA1111
@@ -48,42 +50,47 @@ 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:
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);
};
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
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
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,
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.
@@ -109,6 +116,7 @@ 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.
@@ -118,24 +126,19 @@ So, what's changed?
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
@@ -158,10 +161,9 @@ So, what's changed?
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
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.

61
Documentation/arm/IXP4xx → Documentation/arm/ixp4xx.rst
View File

@@ -1,6 +1,6 @@
-------------------------------------------------------------------------
===========================================================
Release Notes for Linux on Intel's IXP4xx Network Processor
===========================================================
Maintained by Deepak Saxena <dsaxena@plexity.net>
-------------------------------------------------------------------------
@@ -8,7 +8,7 @@ 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
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,
@@ -20,7 +20,7 @@ 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
Intel also made the IXCP1100 CPU for sometime which is an IXP4xx
stripped of much of the network intelligence.
2. Linux Support
@@ -31,7 +31,7 @@ Linux currently supports the following features on the IXP4xx chips:
- PCI interface
- Flash access (MTD/JFFS)
- I2C through GPIO on IXP42x
- GPIO for input/output/interrupts
- GPIO for input/output/interrupts
See arch/arm/mach-ixp4xx/include/mach/platform.h for access functions.
- Timers (watchdog, OS)
@@ -45,7 +45,7 @@ require the use of Intel's proprietary CSR software:
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
http://developer.intel.com/design/network/products/npfamily/ixp425.htm
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY
SOFTWARE.
@@ -53,14 +53,14 @@ 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://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://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
- http://ixp425.sourceforge.net/
ATM device driver for IXP425 that relies on Intel's libraries
3. Known Issues/Limitations
@@ -70,7 +70,7 @@ 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:
@@ -79,15 +79,15 @@ IXP4xx provides two methods of accessing PCI memory space:
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 preffered method due to speed but it
limits the system to just 64MB of PCI memory. This can be
limits the system to just 64MB of PCI memory. This can be
problamatic 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
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.
@@ -96,14 +96,14 @@ 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
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
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
@@ -119,9 +119,9 @@ http://www.gateworks.com/support/overview.php
the expansion bus.
Intel IXDP425 Development Platform
http://www.intel.com/design/network/products/npfamily/ixdpg425.htm
http://www.intel.com/design/network/products/npfamily/ixdpg425.htm
This is Intel's standard reference platform for the IXDP425 and is
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.
@@ -161,11 +161,12 @@ 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]
- Lennerty Buytenhek
- Lutz Jaenicke
- Justin Mayfield
- Robert E. Ranslam
[I know I've forgotten others, please email me to be added]
-------------------------------------------------------------------------

3
Documentation/arm/kernel_mode_neon.txt → Documentation/arm/kernel_mode_neon.rst
View File

@@ -1,3 +1,4 @@
================
Kernel mode NEON
================
@@ -86,6 +87,7 @@ 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
@@ -115,6 +117,7 @@ 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);

79
Documentation/arm/kernel_user_helpers.txt → Documentation/arm/kernel_user_helpers.rst
View File

@@ -1,3 +1,4 @@
============================
Kernel-provided User Helpers
============================
@@ -43,7 +44,7 @@ kuser_helper_version
Location: 0xffff0ffc
Reference declaration:
Reference declaration::
extern int32_t __kuser_helper_version;
@@ -53,17 +54,17 @@ Definition:
running kernel. User space may read this to determine the availability
of a particular helper.
Usage example:
Usage example::
#define __kuser_helper_version (*(int32_t *)0xffff0ffc)
#define __kuser_helper_version (*(int32_t *)0xffff0ffc)
void check_kuser_version(void)
{
void check_kuser_version(void)
{
if (__kuser_helper_version < 2) {
fprintf(stderr, "can't do atomic operations, kernel too old\n");
abort();
}
}
}
Notes:
@@ -77,7 +78,7 @@ kuser_get_tls
Location: 0xffff0fe0
Reference prototype:
Reference prototype::
void * __kuser_get_tls(void);
@@ -97,16 +98,16 @@ Definition:
Get the TLS value as previously set via the __ARM_NR_set_tls syscall.
Usage example:
Usage example::
typedef void * (__kuser_get_tls_t)(void);
#define __kuser_get_tls (*(__kuser_get_tls_t *)0xffff0fe0)
typedef void * (__kuser_get_tls_t)(void);
#define __kuser_get_tls (*(__kuser_get_tls_t *)0xffff0fe0)
void foo()
{
void foo()
{
void *tls = __kuser_get_tls();
printf("TLS = %p\n", tls);
}
}
Notes:
@@ -117,7 +118,7 @@ kuser_cmpxchg
Location: 0xffff0fc0
Reference prototype:
Reference prototype::
int __kuser_cmpxchg(int32_t oldval, int32_t newval, volatile int32_t *ptr);
@@ -139,18 +140,18 @@ Clobbered registers:
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
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:
Usage example::
typedef int (__kuser_cmpxchg_t)(int oldval, int newval, volatile int *ptr);
#define __kuser_cmpxchg (*(__kuser_cmpxchg_t *)0xffff0fc0)
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 atomic_add(volatile int *ptr, int val)
{
int old, new;
do {
@@ -159,7 +160,7 @@ int atomic_add(volatile int *ptr, int val)
} while(__kuser_cmpxchg(old, new, ptr));
return new;
}
}
Notes:
@@ -172,7 +173,7 @@ kuser_memory_barrier
Location: 0xffff0fa0
Reference prototype:
Reference prototype::
void __kuser_memory_barrier(void);
@@ -193,10 +194,10 @@ Definition:
Apply any needed memory barrier to preserve consistency with data modified
manually and __kuser_cmpxchg usage.
Usage example:
Usage example::
typedef void (__kuser_dmb_t)(void);
#define __kuser_dmb (*(__kuser_dmb_t *)0xffff0fa0)
typedef void (__kuser_dmb_t)(void);
#define __kuser_dmb (*(__kuser_dmb_t *)0xffff0fa0)
Notes:
@@ -207,7 +208,7 @@ kuser_cmpxchg64
Location: 0xffff0f60
Reference prototype:
Reference prototype::
int __kuser_cmpxchg64(const int64_t *oldval,
const int64_t *newval,
@@ -231,22 +232,22 @@ Clobbered registers:
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
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
The C flag is also set if `*ptr` was changed to allow for assembly
optimization in the calling code.
Usage example:
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)
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 atomic_add64(volatile int64_t *ptr, int64_t val)
{
int64_t old, new;
do {
@@ -255,7 +256,7 @@ int64_t atomic_add64(volatile int64_t *ptr, int64_t val)
} while(__kuser_cmpxchg64(&old, &new, ptr));
return new;
}
}
Notes:

6
Documentation/arm/keystone/knav-qmss.txt → Documentation/arm/keystone/knav-qmss.rst
View File

@@ -1,4 +1,6 @@
* Texas Instruments Keystone Navigator Queue Management SubSystem driver
======================================================================
Texas Instruments Keystone Navigator Queue Management SubSystem driver
======================================================================
Driver source code path
drivers/soc/ti/knav_qmss.c
@@ -34,11 +36,13 @@ 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 upto 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

47
Documentation/arm/keystone/Overview.txt → Documentation/arm/keystone/overview.rst
View File

@@ -1,5 +1,6 @@
TI Keystone Linux Overview
--------------------------
==========================
TI Keystone Linux Overview
==========================
Introduction
------------
@@ -9,47 +10,65 @@ for users to run Linux on Keystone based EVMs from Texas Instruments.
Following SoCs & EVMs are currently supported:-
------------ K2HK SoC and EVM --------------------------------------------------
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
http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
------------ K2E SoC and EVM ---------------------------------------------------
K2E SoC and EVM
===============
a.k.a Keystone 2 Edison SoC
K2E - 66AK2E05: See documentation at
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
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html
------------ K2L SoC and EVM ---------------------------------------------------
K2L SoC and EVM
===============
a.k.a Keystone 2 Lamarr SoC
K2L - TCI6630K2L: See documentation at
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
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
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/keystone/keystone.txt
Document Author
---------------
Murali Karicheri <m-karicheri2@ti.com>
Copyright 2015 Texas Instruments

488
Documentation/arm/marvel.rst Normal file
View File

@@ -0,0 +1,488 @@
================
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
- 88F5181L
- 88F5182
- Datasheet: http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf
- Programmer's User Guide: http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf
- User Manual: http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf
- 88F5281
- Datasheet: http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
- 88F6183
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 : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
- 88F6283 a.k.a Armada 310
- Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
- 88F6190
- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf
- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
- 88F6192
- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf
- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
- 88F6182
- 88F6180
- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf
- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
- 88F6281
- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf
- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
Homepage:
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 : http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78100-003_WEB.pdf
- Hardware Spec : http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78100_OpenSource.pdf
- Functional Spec: http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
- MV78200
- Product Brief : http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78200-002_WEB.pdf
- Hardware Spec : http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78200_OpenSource.pdf
- Functional Spec: http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
- MV76100
Not supported by the Linux kernel.
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 Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
- Hardware Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
- Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
Core:
Sheeva ARMv7 compatible PJ4B
Armada 375 Flavors:
- 88F6720
- Product Brief: 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
- 88F6820 Armada 385
- 88F6828 Armada 388
- Product infos: http://www.marvell.com/embedded-processors/armada-38x/
- Functional Spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/
Core:
ARM Cortex-A9
Armada 39x Flavors:
- 88F6920 Armada 390
- 88F6928 Armada 398
- Product infos: http://www.marvell.com/embedded-processors/armada-39x/
Core:
ARM Cortex-A9
Armada XP Flavors:
- MV78230
- MV78260
- MV78460
NOTE:
not to be confused with the non-SMP 78xx0 SoCs
Product Brief:
http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
Functional Spec:
http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
- Hardware Specs:
- http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
- http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
- http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
Core:
Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP
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:
http://www.marvell.com/embedded-processors/armada-3700/
Product Brief:
http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
Device tree files:
arch/arm64/boot/dts/marvell/armada-37*
Armada 7K Flavors:
- 88F7020 (AP806 Dual + one CP110)
- 88F7040 (AP806 Quad + one CP110)
Core: ARM Cortex A72
Homepage:
http://www.marvell.com/embedded-processors/armada-70xx/
Product Brief:
- http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf
- 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:
http://www.marvell.com/embedded-processors/armada-80xx/
Product Brief:
- http://www.marvell.com/embedded-processors/assets/Armada8020PB-Jan2016.pdf
- http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf
Device tree files:
arch/arm64/boot/dts/marvell/armada-80*
Avanta family
-------------
Flavors:
- 88F6510
- 88F6530P
- 88F6550
- 88F6560
Homepage:
http://www.marvell.com/broadband/
Product Brief:
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:
http://www.marvell.com/storage/armada-sp/
Core:
Sheeva ARMv7 comatible Quad-core PJ4C
(not supported in upstream Linux kernel)
Dove family (application processor)
-----------------------------------
Flavors:
- 88AP510 a.k.a Armada 510
Product Brief:
http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf
Hardware Spec:
http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Hardware-Spec.pdf
Functional Spec:
http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
Homepage:
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 : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
- Design guide : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
- Developers manual : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_dev_man.pdf
- Specification : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
- Specification update : 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 : http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
- PXA 310 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
- PXA 320 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA320_PB_R4.pdf
- Design guide : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Design_Guide.pdf
- Developers manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip
- Specifications : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_EMTS.pdf
- Specification Update : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
- Reference Manual : 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
Linux kernel plat directory:
arch/arm/plat-pxa
MMP/MMP2/MMP3 family (communication processor)
----------------------------------------------
Flavors:
- PXA168, a.k.a Armada 168
- Homepage : http://www.marvell.com/application-processors/armada-100/armada-168.jsp
- Product brief : http://www.marvell.com/application-processors/armada-100/assets/pxa_168_pb.pdf
- Hardware manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_datasheet.pdf
- Software manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_software_manual.pdf
- Specification update : http://www.marvell.com/application-processors/armada-100/assets/ARMADA16x_Spec_update.pdf
- Boot ROM manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
- App node package : 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 : http://www.marvell.com/communication-processors/pxa910/
- Product Brief : http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf
- Application processor with Communication processor
- Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
- PXA688, a.k.a. MMP2, a.k.a Armada 610
- Product Brief : 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 (OLPC XO4, Linux support not upstream)
- Product Brief : 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
Linux kernel plat directory:
arch/arm/plat-pxa
Berlin family (Multimedia Solutions)
-------------------------------------
- Flavors:
- 88DE3010, Armada 1000 (no Linux support)
- Core: Marvell PJ1 (ARMv5TE), Dual-core
- Product Brief: http://www.marvell.com.cn/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.
* Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
directory. The plat-pxa/ 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>

11
Documentation/arm/mem_alignment → Documentation/arm/mem_alignment.rst
View File

@@ -1,3 +1,7 @@
================
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
@@ -26,9 +30,9 @@ 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
@@ -41,12 +45,13 @@ bit behavior when set
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:
fixing up or sending SIGBUS signals::
echo 1 > /proc/cpu/alignment

9
Documentation/arm/memory.txt → Documentation/arm/memory.rst
View File

@@ -1,6 +1,9 @@
Kernel Memory Layout on ARM Linux
=================================
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
@@ -15,8 +18,9 @@ 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.
@@ -77,6 +81,7 @@ MODULES_VADDR MODULES_END-1 Kernel module space
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

63
Documentation/arm/Microchip/README → Documentation/arm/microchip.rst
View File

@@ -1,3 +1,4 @@
=============================
ARM Microchip SoCs (aka AT91)
=============================
@@ -22,32 +23,46 @@ the Microchip website: http://www.microchip.com.
Flavors:
* ARM 920 based SoC
- at91rm9200
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-1768-32-bit-ARM920T-Embedded-Microprocessor-AT91RM9200_Datasheet.pdf
* ARM 926 based SoCs
- at91sam9260
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6221-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9260_Datasheet.pdf
- at91sam9xe
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6254-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9XE_Datasheet.pdf
- at91sam9261
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6062-ARM926EJ-S-Microprocessor-SAM9261_Datasheet.pdf
- at91sam9263
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6249-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9263_Datasheet.pdf
- at91sam9rl
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/doc6289.pdf
- at91sam9g20
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001516A.pdf
- at91sam9g45 family
@@ -55,7 +70,9 @@ the Microchip website: http://www.microchip.com.
- at91sam9g46
- at91sam9m10
- at91sam9m11 (device superset)
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6437-32-bit-ARM926-Embedded-Microprocessor-SAM9M11_Datasheet.pdf
- at91sam9x5 family (aka "The 5 series")
@@ -64,33 +81,44 @@ the Microchip website: http://www.microchip.com.
- at91sam9g35
- at91sam9x25
- at91sam9x35
+ Datasheet (can be considered as covering the whole family)
* 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
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001517A.pdf
* ARM Cortex-A5 based SoCs
- sama5d3 family
- sama5d31
- sama5d33
- sama5d34
- sama5d35
- sama5d36 (device superset)
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet.pdf
* ARM Cortex-A5 + NEON based SoCs
- sama5d4 family
- sama5d41
- sama5d42
- sama5d43
- sama5d44 (device superset)
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/60001525A.pdf
- sama5d2 family
- sama5d21
- sama5d22
- sama5d23
@@ -98,11 +126,14 @@ the Microchip website: http://www.microchip.com.
- sama5d26
- sama5d27 (device superset)
- sama5d28 (device superset + environmental monitors)
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001476B.pdf
* ARM Cortex-M7 MCUs
- sams70 family
- sams70j19
- sams70j20
- sams70j21
@@ -114,6 +145,7 @@ the Microchip website: http://www.microchip.com.
- sams70q21
- samv70 family
- samv70j19
- samv70j20
- samv70n19
@@ -122,6 +154,7 @@ the Microchip website: http://www.microchip.com.
- samv70q20
- samv71 family
- samv71j19
- samv71j20
- samv71j21
@@ -132,7 +165,8 @@ the Microchip website: http://www.microchip.com.
- samv71q20
- samv71q21
+ Datasheet
* Datasheet
http://ww1.microchip.com/downloads/en/DeviceDoc/60001527A.pdf
@@ -157,6 +191,7 @@ 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

Some files were not shown because too many files have changed in this diff Show More