linux_dsm_epyc7002/Documentation/arm
Linus Torvalds 93335e5911 ARM: SoC device tree updates for 4.20
There are close to 800 indivudal changesets in this branch again, which
 feels like a lot. There are particularly many changes for the NVIDIA
 Tegra platform this time, in fact more than it has seen in the two years
 since the v4.9 merge window. Aside from this, it's been fairly normal,
 with lots of changes going into Renesas R-CAR, NXP i.MX, Allwinner Sunxi,
 Samsung Exynos, and TI OMAP.
 
 Most of the changes are for adding new features into existing boards,
 for brevity I'm only mentioning completely new machines and SoCs here.
 For the first time I think we have (slightly) more new 64-bit hardware
 than 32-bit:
 
 Two boards get added for TI OMAP: Moxa UC-2101 is an industrial
 computer, see https://www.moxa.com/product/UC-2100.htm; GTA04A5
 is a minor variation of the motherboards of the GTA04 phone, see
 https://shop.goldelico.com/wiki.php?page=GTA04A5
 
 Clearfog is a nice little board for quad-core
 Marvell Armada 8040 network processor, see
 https://www.solid-run.com/marvell-armada-family/clearfog-gt-8k/
 
 Two additional server boards come with the Aspeed baseboard management
 controllers: Stardragon4800 is an arm64 reference platform made by HXT
 (based on Qualcomm's server chips), and TiogaPass is an Open Compute
 mainboard with x86 CPUs. Both use the ARM11 based AST2500 chips in
 the BMC.
 
 NXP i.MX usually sees a lot of new boards each release. This time there
 we only add one minor variant: ConnectCore 6UL SBC Pro uses the same
 SoM design as the ConnectCore 6UL SBC Express added later. However,
 there is a new chip, the i.MX6ULZ, which is an even smaller variant
 of the i.MX6ULL, with features removed. There is also support for the
 reference board design, the i.MX6ULZ 14x14 EVK.
 
 A new Raspberry Pi variant gets added, this one is the CM3 compute module
 based on bcm2837, it was launched in early 2017 but only now added to
 the kernel, both as 32-bit and as 64-bit files, as we tend to do for
 Raspberry Pi.
 
 On the Allwinner side, everything is again about cheap development
 boards, usually of the "Fruit Pi" variety. The new ones this time
 are:
 Orange Pi Zero Plus2: http://www.orangepi.org/OrangePiZeroPlus2/
 Orange Pi One Plus: http://www.orangepi.org/OrangePiOneplus/
 Pine64 LTS: https://www.pine64.org/?product=pine-a64-lts
 Banana Pi M2+ H5: http://www.banana-pi.org/m2plus.html
 The last one of these is now a 64-bit version of the earlier Banana
 Pi M2+ H3, with the same board layout.
 
 Similarly, for Rockchips, get get another variant of the 32-bit
 Asus Tinker board, the model 'S' based on rk3288, and three now
 boards based on the popular RK3399 chip:
 ROC-RK3399-PC: https://libre.computer/products/boards/roc-rk3399-pc/
 Rock960: https://www.96boards.org/product/rock960/
 RockPro64: https://www.pine64.org/?page_id=61454
 These are all quite powerful boards with lots of RAM and I/O, and
 the RK3399 is the same chip used in several Chromebooks.  Finally,
 we get support for the PX30 (aka rk3326) chip, which is based on the
 low-end 64-bit Cortex-A35 CPU core. So far, only the evaluation board
 is supported.
 
 One more Banana Pi is added with a Mediatek chip: Banana Pi R64 is based
 on the MT7622 WiFi router platform, and the first product I've seen with
 a 64-bit Mediatek chip in that market: http://www.banana-pi.org/r64.html
 
 For HiSilicon, we gain support for the Hi3670 SoC and HiKey 370
 development board, which are similar to the Hi3660 and Hikey 360
 respectively, but add support for an NPU.
 
 Amlogic gets initial support for the Meson-G12A chip (S905D2),
 another quad-core Cortex-A53 SoC, and its evaluation platform.
 On the 32-bit side, we gain support for an actual end-user product,
 the Endless Computers Endless Mini based on Meson8b (S805), see
 https://endlessos.com/computers/
 
 Qualcomm adds support for their MSM8998 SoC and evaluation platform. This
 chip is commonly known as the Snapdragon 835, and is used in high-end
 phones as well as low-end laptops.
 
 For Renesas, a very bare support for the r8a774a1 (RZ/G2M) is added,
 but no boards for this one. However, we do add boards for the previously
 added r8a77965 (R-Car M3-N): the M3NULCB Kingfisher and the M3NULCB
 Starter Kit Pro.
 
 While we have lots of DT changes for NVIDIA to update the existing files,
 the only board that gets added is the Toradex Colibri T20 on Colibri
 Evaluation Board for the old Tegra2.
 
 Synaptics add support for their AS370 SoC, which is part of the (formerly
 Marvell) Berlin line of set-top-box chips used e.g.  in the various Google
 Chromecast. Only the .dtsi gets added at this point, no actual machines.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJb1224AAoJEGCrR//JCVIn9uYP/jLMoGkVQRS5L9sRjOci1l5b
 EHl8veJ+uNJaTStp5XAZk90MoBcSdXtnISSEiR7a3qKJw1mYfgAWyPtQCttRFUCo
 rDp4GJpJ96TBg1tyt5Lop3V9eIYbCh9epf2foKTTdpRiX022AFk1031jvnh2Teuy
 fKA2VNeoyyOZqxh0ysJq7G8kWt8PTQTKXDebYPWEbsu0AFmqQ84lz7oGNdPk0GPm
 krtQIO6rh+sJR/8wWGYfnTYAIOk6jNrPhiyjEcyu+x2525rwKxJNKVY8P9PuNhrl
 hzqld1dPtb3gfdcxWxZUznHmVUGkVEIa1QNC6csSmLzuxqJJE0/J5u2P8lIfrhVI
 c5C8r3eaTxFM0s5uKhNhhewlJ6uiDhUQy13AG0JXteujP23BGObYstnV10pJrH75
 xq7uSUiU04v95MocPjodJ2I7dIlAoFCd6ELnsmD/mz743gY9AZ6DHaOBMMwIzK3H
 EQifF5E/4PWOjBx7fonumBm0LebPjWGmv4CNyCK5Q93ylK7U/kFDdjiNjNhyks5E
 CVQBFhA7sshKJQRDOiaofMxOfKJHeKGU2PR7yGRpT3YWQD/apIL/elG4qUNjLX46
 2Dwdgq8nDdbY2SzPwwy7ncTtyDRYcsFCtScT5slu1I1UxIhwEYJurzCKDM4jJNZb
 Cg2D7a+AlZ8N5Vsr1ldV
 =yaED
 -----END PGP SIGNATURE-----

Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC device tree updates from Arnd Bergmann:
 "There are close to 800 indivudal changesets in this branch again,
  which feels like a lot. There are particularly many changes for the
  NVIDIA Tegra platform this time, in fact more than it has seen in the
  two years since the v4.9 merge window. Aside from this, it's been
  fairly normal, with lots of changes going into Renesas R-CAR, NXP
  i.MX, Allwinner Sunxi, Samsung Exynos, and TI OMAP.

  Most of the changes are for adding new features into existing boards,
  for brevity I'm only mentioning completely new machines and SoCs here.
  For the first time I think we have (slightly) more new 64-bit hardware
  than 32-bit:

  Two boards get added for TI OMAP: Moxa UC-2101 is an industrial
  computer, see https://www.moxa.com/product/UC-2100.htm; GTA04A5 is a
  minor variation of the motherboards of the GTA04 phone, see
  https://shop.goldelico.com/wiki.php?page=GTA04A5

  Clearfog is a nice little board for quad-core Marvell Armada 8040
  network processor, see
  https://www.solid-run.com/marvell-armada-family/clearfog-gt-8k/

  Two additional server boards come with the Aspeed baseboard management
  controllers: Stardragon4800 is an arm64 reference platform made by HXT
  (based on Qualcomm's server chips), and TiogaPass is an Open Compute
  mainboard with x86 CPUs. Both use the ARM11 based AST2500 chips in the
  BMC.

  NXP i.MX usually sees a lot of new boards each release. This time
  there we only add one minor variant: ConnectCore 6UL SBC Pro uses the
  same SoM design as the ConnectCore 6UL SBC Express added later.
  However, there is a new chip, the i.MX6ULZ, which is an even smaller
  variant of the i.MX6ULL, with features removed. There is also support
  for the reference board design, the i.MX6ULZ 14x14 EVK.

  A new Raspberry Pi variant gets added, this one is the CM3 compute
  module based on bcm2837, it was launched in early 2017 but only now
  added to the kernel, both as 32-bit and as 64-bit files, as we tend to
  do for Raspberry Pi.

  On the Allwinner side, everything is again about cheap development
  boards, usually of the "Fruit Pi" variety. The new ones this time are:
   - Orange Pi Zero Plus2: http://www.orangepi.org/OrangePiZeroPlus2/
   - Orange Pi One Plus: http://www.orangepi.org/OrangePiOneplus/
   - Pine64 LTS: https://www.pine64.org/?product=pine-a64-lts
   - Banana Pi M2+ H5: http://www.banana-pi.org/m2plus.html
  The last one of these is now a 64-bit version of the earlier Banana Pi
  M2+ H3, with the same board layout.

  Similarly, for Rockchips, get get another variant of the 32-bit Asus
  Tinker board, the model 'S' based on rk3288, and three now boards
  based on the popular RK3399 chip:
   - ROC-RK3399-PC: https://libre.computer/products/boards/roc-rk3399-pc/
   - Rock960: https://www.96boards.org/product/rock960/
   - RockPro64: https://www.pine64.org/?page_id=61454
  These are all quite powerful boards with lots of RAM and I/O, and the
  RK3399 is the same chip used in several Chromebooks. Finally, we get
  support for the PX30 (aka rk3326) chip, which is based on the low-end
  64-bit Cortex-A35 CPU core. So far, only the evaluation board is
  supported.

  One more Banana Pi is added with a Mediatek chip: Banana Pi R64 is
  based on the MT7622 WiFi router platform, and the first product I've
  seen with a 64-bit Mediatek chip in that market:
  http://www.banana-pi.org/r64.html

  For HiSilicon, we gain support for the Hi3670 SoC and HiKey 370
  development board, which are similar to the Hi3660 and Hikey 360
  respectively, but add support for an NPU.

  Amlogic gets initial support for the Meson-G12A chip (S905D2), another
  quad-core Cortex-A53 SoC, and its evaluation platform. On the 32-bit
  side, we gain support for an actual end-user product, the Endless
  Computers Endless Mini based on Meson8b (S805), see
  https://endlessos.com/computers/

  Qualcomm adds support for their MSM8998 SoC and evaluation platform.
  This chip is commonly known as the Snapdragon 835, and is used in
  high-end phones as well as low-end laptops.

  For Renesas, a very bare support for the r8a774a1 (RZ/G2M) is added,
  but no boards for this one. However, we do add boards for the
  previously added r8a77965 (R-Car M3-N): the M3NULCB Kingfisher and the
  M3NULCB Starter Kit Pro.

  While we have lots of DT changes for NVIDIA to update the existing
  files, the only board that gets added is the Toradex Colibri T20 on
  Colibri Evaluation Board for the old Tegra2.

  Synaptics add support for their AS370 SoC, which is part of the
  (formerly Marvell) Berlin line of set-top-box chips used e.g. in the
  various Google Chromecast. Only the .dtsi gets added at this point, no
  actual machines"

* tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (721 commits)
  ARM: dts: socfgpa: remove ethernet aliases from dtsi
  arm64: dts: stratix10: add ethernet aliases
  dt-bindings: mediatek: Add bindig for MT7623 IOMMU and SMI
  dt-bindings: mediatek: Add JPEG Decoder binding for MT7623
  dt-bindings: iommu: mediatek: Add binding for MT7623
  dt-bindings: clock: mediatek: add support for MT7623
  ARM: dts: mvebu: armada-385-db-88f6820-amc: auto-detect nand ECC properites
  ARM: dts: da850-lego-ev3: slow down A/DC as much as possible
  ARM: dts: da850-evm: Enable tca6416 on baseboard
  arm64: dts: uniphier: Add USB2 PHY nodes
  arm64: dts: uniphier: Add USB3 controller nodes
  ARM: dts: uniphier: Add USB2 PHY nodes
  ARM: dts: uniphier: Add USB3 controller nodes
  arm64: dts: meson-axg: s400: disable emmc
  arm64: dts: meson-axg: s400: add missing emmc pwrseq
  arm64: dts: clearfog-gt-8k: add PCIe slot description
  ARM: dts: at91: sama5d4_xplained: even nand memory partitions
  ARM: dts: at91: sama5d3_xplained: even nand memory partitions
  ARM: dts: at91: at91sam9x5cm: even nand memory partitions
  ARM: dts: at91: sama5d2_ptc_ek: fix bootloader env offsets
  ...
2018-10-29 15:05:20 -07:00
..
keystone ARM: dts: keystone: k2l: fix kernel crash when clk_ignore_unused is not in bootargs 2015-11-23 10:36:27 -08:00
Marvell Documentation: arm: clean up Marvell Berlin family info 2018-05-16 13:11:57 -06:00
Microchip Documentation: at91: Update Microchip SoC documentation 2018-02-28 16:21:51 +01:00
nwfpe
OMAP Documentation: ARM: Add new MMC requirements for DRA7/K2G 2018-05-03 10:32:20 -07:00
pxa ARM: pxa: make more mach/*.h files local 2015-12-01 21:52:50 +01:00
SA1100 Documentation: fix common spelling mistakes 2016-04-28 07:51:59 -06:00
Samsung ARM: exynos: Fix imprecise abort during Exynos5422 suspend to RAM 2018-08-30 19:46:06 +02:00
Samsung-S3C24XX mtd: nand: move raw NAND related code to the raw/ subdir 2018-02-16 10:09:34 +01:00
SH-Mobile
SPEAr
sti
stm32 ARM: stm32: add initial support for STM32MP157 2018-03-05 09:08:43 +01:00
sunxi ARM: sunxi: add support for R40 SoC 2017-09-22 21:57:09 +02:00
VFP
Booting docs: fix locations of several documents that got moved 2016-10-24 08:12:35 -02:00
cluster-pm-race-avoidance.txt
firmware.txt Documentation: arm: Replace use of virt_to_phys with __pa_symbol 2017-07-17 13:43:58 -06:00
Interrupts
IXP4xx
kernel_mode_neon.txt
kernel_user_helpers.txt
mem_alignment arm: Documentation: update a path name 2017-04-20 14:06:55 -06:00
memory.txt
Netwinder
Porting
README
Setup
swp_emulation
tcm.txt
uefi.txt
vlocks.txt

			   ARM Linux 2.6
			   =============

    Please check <ftp://ftp.arm.linux.org.uk/pub/armlinux> for
    updates.

Compilation of kernel
---------------------

  In order to compile ARM Linux, you will need a compiler capable of
  generating ARM ELF code with GNU extensions.  GCC 3.3 is known to be
  a good compiler.  Fortunately, you needn't guess.  The kernel will report
  an error if your compiler is a recognized offender.

  To build ARM Linux natively, you shouldn't have to alter the ARCH = line
  in the top level Makefile.  However, if you don't have the ARM Linux ELF
  tools installed as default, then you should change the CROSS_COMPILE
  line as detailed below.

  If you wish to cross-compile, then alter the following lines in the top
  level make file:

    ARCH = <whatever>
	with
    ARCH = arm

	and

    CROSS_COMPILE=
	to
    CROSS_COMPILE=<your-path-to-your-compiler-without-gcc>
	eg.
    CROSS_COMPILE=arm-linux-

  Do a 'make config', followed by 'make Image' to build the kernel 
  (arch/arm/boot/Image).  A compressed image can be built by doing a 
  'make zImage' instead of 'make Image'.


Bug reports etc
---------------

  Please send patches to the patch system.  For more information, see
  http://www.arm.linux.org.uk/developer/patches/info.php Always include some
  explanation as to what the patch does and why it is needed.

  Bug reports should be sent to linux-arm-kernel@lists.arm.linux.org.uk,
  or submitted through the web form at
  http://www.arm.linux.org.uk/developer/ 

  When sending bug reports, please ensure that they contain all relevant
  information, eg. the kernel messages that were printed before/during
  the problem, what you were doing, etc.


Include files
-------------

  Several new include directories have been created under include/asm-arm,
  which are there to reduce the clutter in the top-level directory.  These
  directories, and their purpose is listed below:

   arch-*	machine/platform specific header files
   hardware	driver-internal ARM specific data structures/definitions
   mach		descriptions of generic ARM to specific machine interfaces
   proc-*	processor dependent header files (currently only two
		categories)


Machine/Platform support
------------------------

  The ARM tree contains support for a lot of different machine types.  To
  continue supporting these differences, it has become necessary to split
  machine-specific parts by directory.  For this, the machine category is
  used to select which directories and files get included (we will use
  $(MACHINE) to refer to the category)

  To this end, we now have arch/arm/mach-$(MACHINE) directories which are
  designed to house the non-driver files for a particular machine (eg, PCI,
  memory management, architecture definitions etc).  For all future
  machines, there should be a corresponding arch/arm/mach-$(MACHINE)/include/mach
  directory.


Modules
-------

  Although modularisation is supported (and required for the FP emulator),
  each module on an ARM2/ARM250/ARM3 machine when is loaded will take
  memory up to the next 32k boundary due to the size of the pages.
  Therefore, is modularisation on these machines really worth it?

  However, ARM6 and up machines allow modules to take multiples of 4k, and
  as such Acorn RiscPCs and other architectures using these processors can
  make good use of modularisation.


ADFS Image files
----------------

  You can access image files on your ADFS partitions by mounting the ADFS
  partition, and then using the loopback device driver.  You must have
  losetup installed.

  Please note that the PCEmulator DOS partitions have a partition table at
  the start, and as such, you will have to give '-o offset' to losetup.


Request to developers
---------------------

  When writing device drivers which include a separate assembler file, please
  include it in with the C file, and not the arch/arm/lib directory.  This
  allows the driver to be compiled as a loadable module without requiring
  half the code to be compiled into the kernel image.

  In general, try to avoid using assembler unless it is really necessary.  It
  makes drivers far less easy to port to other hardware.


ST506 hard drives
-----------------

  The ST506 hard drive controllers seem to be working fine (if a little
  slowly).  At the moment they will only work off the controllers on an
  A4x0's motherboard, but for it to work off a Podule just requires
  someone with a podule to add the addresses for the IRQ mask and the
  HDC base to the source.

  As of 31/3/96 it works with two drives (you should get the ADFS
  *configure harddrive set to 2). I've got an internal 20MB and a great
  big external 5.25" FH 64MB drive (who could ever want more :-) ).

  I've just got 240K/s off it (a dd with bs=128k); thats about half of what
  RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting
  last week :-)

  Known bug: Drive data errors can cause a hang; including cases where
  the controller has fixed the error using ECC. (Possibly ONLY
  in that case...hmm).


1772 Floppy
-----------
  This also seems to work OK, but hasn't been stressed much lately.  It
  hasn't got any code for disc change detection in there at the moment which
  could be a bit of a problem!  Suggestions on the correct way to do this
  are welcome.


CONFIG_MACH_ and CONFIG_ARCH_
-----------------------------
  A change was made in 2003 to the macro names for new machines.
  Historically, CONFIG_ARCH_ was used for the bonafide architecture,
  e.g. SA1100, as well as implementations of the architecture,
  e.g. Assabet.  It was decided to change the implementation macros
  to read CONFIG_MACH_ for clarity.  Moreover, a retroactive fixup has
  not been made because it would complicate patching.

  Previous registrations may be found online.

    <http://www.arm.linux.org.uk/developer/machines/>

Kernel entry (head.S)
--------------------------
  The initial entry into the kernel is via head.S, which uses machine
  independent code.  The machine is selected by the value of 'r1' on
  entry, which must be kept unique.

  Due to the large number of machines which the ARM port of Linux provides
  for, we have a method to manage this which ensures that we don't end up
  duplicating large amounts of code.

  We group machine (or platform) support code into machine classes.  A
  class typically based around one or more system on a chip devices, and
  acts as a natural container around the actual implementations.  These
  classes are given directories - arch/arm/mach-<class> and
  arch/arm/mach-<class> - which contain the source files to/include/mach
  support the machine class.  This directories also contain any machine
  specific supporting code.

  For example, the SA1100 class is based upon the SA1100 and SA1110 SoC
  devices, and contains the code to support the way the on-board and off-
  board devices are used, or the device is setup, and provides that
  machine specific "personality."

  For platforms that support device tree (DT), the machine selection is
  controlled at runtime by passing the device tree blob to the kernel.  At
  compile-time, support for the machine type must be selected.  This allows for
  a single multiplatform kernel build to be used for several machine types.

  For platforms that do not use device tree, this machine selection is
  controlled by the machine type ID, which acts both as a run-time and a
  compile-time code selection method.  You can register a new machine via the
  web site at:

    <http://www.arm.linux.org.uk/developer/machines/>

  Note: Please do not register a machine type for DT-only platforms.  If your
  platform is DT-only, you do not need a registered machine type.

---
Russell King (15/03/2004)