code:
================
ARM Marvell SoCs
================

This document lists all the ARM Marvell SoCs that are currently
supported in mainline by the Linux kernel. As the Marvell families of
SoCs are large and complex, it is hard to understand where the support
for a particular SoC is available in the Linux kernel. This document
tries to help in understanding where those SoCs are supported, and to
match them with their corresponding public datasheet, when available.

Orion family
------------

  Flavors:
        - 88F5082
        - 88F5181  a.k.a Orion-1
        - 88F5181L a.k.a Orion-VoIP
        - 88F5182  a.k.a Orion-NAS

               - Datasheet: https://web.archive.org/web/20210124231420/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-datasheet.pdf
               - Programmer's User Guide: https://web.archive.org/web/20210124231536/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-opensource-manual.pdf
               - User Manual: https://web.archive.org/web/20210124231631/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-usermanual.pdf
               - Functional Errata: https://web.archive.org/web/20210704165540/https://www.digriz.org.uk/ts78xx/88F5182_Functional_Errata.pdf
        - 88F5281  a.k.a Orion-2

               - Datasheet: https://web.archive.org/web/20131028144728/http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
        - 88F6183  a.k.a Orion-1-90
  Homepage:
        https://web.archive.org/web/20080607215437/http://www.marvell.com/products/media/index.jsp
  Core:
	Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible
  Linux kernel mach directory:
	arch/arm/mach-orion5x
  Linux kernel plat directory:
	arch/arm/plat-orion

Kirkwood family
---------------

  Flavors:
        - 88F6282 a.k.a Armada 300

                - Product Brief  : https://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
        - 88F6283 a.k.a Armada 310

                - Product Brief  : https://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf
        - 88F6190

                - Product Brief  : https://web.archive.org/web/20130730072715/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf
                - Hardware Spec  : https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
                - Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
        - 88F6192

                - Product Brief  : https://web.archive.org/web/20131113121446/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf
                - Hardware Spec  : https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf
                - Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
        - 88F6182
        - 88F6180

                - Product Brief  : https://web.archive.org/web/20120616201621/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf
                - Hardware Spec  : https://web.archive.org/web/20130730091654/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
                - Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
        - 88F6280

                - Product Brief  : https://web.archive.org/web/20130730091058/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6280_SoC_PB-001.pdf
        - 88F6281

                - Product Brief  : https://web.archive.org/web/20120131133709/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf
                - Hardware Spec  : https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
                - Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
        - 88F6321
        - 88F6322
        - 88F6323

                - Product Brief  : https://web.archive.org/web/20120616201639/http://www.marvell.com/embedded-processors/kirkwood/assets/88f632x_pb.pdf
  Homepage:
	https://web.archive.org/web/20160513194943/http://www.marvell.com/embedded-processors/kirkwood/
  Core:
	Feroceon 88fr131 ARMv5 compatible
  Linux kernel mach directory:
	arch/arm/mach-mvebu
  Linux kernel plat directory:
	none

Discovery family
----------------

  Flavors:
        - MV78100

                - Product Brief  : https://web.archive.org/web/20120616194711/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78100-003_WEB.pdf
                - Hardware Spec  : https://web.archive.org/web/20141005120451/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78100_OpenSource.pdf
                - Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
        - MV78200

                - Product Brief  : https://web.archive.org/web/20140801121623/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78200-002_WEB.pdf
                - Hardware Spec  : https://web.archive.org/web/20141005120458/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78200_OpenSource.pdf
                - Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf

        - MV76100

                - Product Brief  : https://web.archive.org/web/20140722064429/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV76100-002_WEB.pdf
                - Hardware Spec  : https://web.archive.org/web/20140722064425/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV76100_OpenSource.pdf
                - Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf

                Not supported by the Linux kernel.

  Homepage:
        https://web.archive.org/web/20110924171043/http://www.marvell.com/embedded-processors/discovery-innovation/
  Core:
	Feroceon 88fr571-vd ARMv5 compatible

  Linux kernel mach directory:
	arch/arm/mach-mv78xx0
  Linux kernel plat directory:
	arch/arm/plat-orion

EBU Armada family
-----------------

  Armada 370 Flavors:
        - 88F6710
        - 88F6707
        - 88F6W11

    - Product infos:   https://web.archive.org/web/20141002083258/http://www.marvell.com/embedded-processors/armada-370/
    - Product Brief:   https://web.archive.org/web/20121115063038/http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
    - Hardware Spec:   https://web.archive.org/web/20140617183747/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
    - Functional Spec: https://web.archive.org/web/20140617183701/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf

  Core:
	Sheeva ARMv7 compatible PJ4B

  Armada XP Flavors:
        - MV78230
        - MV78260
        - MV78460

    NOTE:
	not to be confused with the non-SMP 78xx0 SoCs

    - Product infos:   https://web.archive.org/web/20150101215721/http://www.marvell.com/embedded-processors/armada-xp/
    - Product Brief:   https://web.archive.org/web/20121021173528/http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
    - Functional Spec: https://web.archive.org/web/20180829171131/http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
    - Hardware Specs:
        - https://web.archive.org/web/20141127013651/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
        - https://web.archive.org/web/20141222000224/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
        - https://web.archive.org/web/20141222000230/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF

  Core:
	Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP

  Armada 375 Flavors:
	- 88F6720

    - Product infos: https://web.archive.org/web/20140108032402/http://www.marvell.com/embedded-processors/armada-375/
    - Product Brief: https://web.archive.org/web/20131216023516/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf

  Core:
	ARM Cortex-A9

  Armada 38x Flavors:
	- 88F6810	Armada 380
	- 88F6811 Armada 381
	- 88F6821 Armada 382
	- 88F6W21 Armada 383
	- 88F6820 Armada 385
	- 88F6825
	- 88F6828 Armada 388

    - Product infos:   https://web.archive.org/web/20181006144616/http://www.marvell.com/embedded-processors/armada-38x/
    - Functional Spec: https://web.archive.org/web/20200420191927/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf
    - Hardware Spec:   https://web.archive.org/web/20180713105318/https://www.marvell.com/docs/embedded-processors/assets/marvell-embedded-processors-armada-38x-hardware-specifications-2017-03.pdf
    - Design guide:    https://web.archive.org/web/20180712231737/https://www.marvell.com/docs/embedded-processors/assets/marvell-embedded-processors-armada-38x-hardware-design-guide-2017-08.pdf

  Core:
	ARM Cortex-A9

  Armada 39x Flavors:
	- 88F6920 Armada 390
	- 88F6925 Armada 395
	- 88F6928 Armada 398

    - Product infos: https://web.archive.org/web/20181020222559/http://www.marvell.com/embedded-processors/armada-39x/

  Core:
	ARM Cortex-A9

  Linux kernel mach directory:
	arch/arm/mach-mvebu
  Linux kernel plat directory:
	none

EBU Armada family ARMv8
-----------------------

  Armada 3710/3720 Flavors:
	- 88F3710
	- 88F3720

  Core:
	ARM Cortex A53 (ARMv8)

  Homepage:
	https://web.archive.org/web/20181103003602/http://www.marvell.com/embedded-processors/armada-3700/

  Product Brief:
	https://web.archive.org/web/20210121194810/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-product-brief-2016-01.pdf

  Hardware Spec:
	https://web.archive.org/web/20210202162011/http://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-hardware-specifications-2019-09.pdf

  Device tree files:
	arch/arm64/boot/dts/marvell/armada-37*

  Armada 7K Flavors:
	  - 88F6040 (AP806 Quad 600 MHz + one CP110)
	  - 88F7020 (AP806 Dual + one CP110)
	  - 88F7040 (AP806 Quad + one CP110)

  Core: ARM Cortex A72

  Homepage:
	https://web.archive.org/web/20181020222606/http://www.marvell.com/embedded-processors/armada-70xx/

  Product Brief:
	  - https://web.archive.org/web/20161010105541/http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf
	  - https://web.archive.org/web/20160928154533/http://www.marvell.com/embedded-processors/assets/Armada7040PB-Jan2016.pdf

  Device tree files:
	arch/arm64/boot/dts/marvell/armada-70*

  Armada 8K Flavors:
	- 88F8020 (AP806 Dual + two CP110)
	- 88F8040 (AP806 Quad + two CP110)
  Core:
	ARM Cortex A72

  Homepage:
	https://web.archive.org/web/20181022004830/http://www.marvell.com/embedded-processors/armada-80xx/

  Product Brief:
	  - https://web.archive.org/web/20210124233728/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-8020-product-brief-2017-12.pdf
	  - https://web.archive.org/web/20161010105532/http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf

  Device tree files:
	arch/arm64/boot/dts/marvell/armada-80*

  Octeon TX2 CN913x Flavors:
	- CN9130 (AP807 Quad + one internal CP115)
	- CN9131 (AP807 Quad + one internal CP115 + one external CP115 / 88F8215)
	- CN9132 (AP807 Quad + one internal CP115 + two external CP115 / 88F8215)

  Core:
	ARM Cortex A72

  Homepage:
	https://web.archive.org/web/20200803150818/https://www.marvell.com/products/infrastructure-processors/multi-core-processors/octeon-tx2/octeon-tx2-cn9130.html

  Product Brief:
	https://web.archive.org/web/20200803150818/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-infrastructure-processors-octeon-tx2-cn913x-product-brief-2020-02.pdf

  Device tree files:
	arch/arm64/boot/dts/marvell/cn913*

Avanta family
-------------

  Flavors:
       - 88F6500
       - 88F6510
       - 88F6530P
       - 88F6550
       - 88F6560
       - 88F6601

  Homepage:
	https://web.archive.org/web/20181005145041/http://www.marvell.com/broadband/

  Product Brief:
	https://web.archive.org/web/20180829171057/http://www.marvell.com/broadband/assets/Marvell_Avanta_88F6510_305_060-001_product_brief.pdf

  No public datasheet available.

  Core:
	ARMv5 compatible

  Linux kernel mach directory:
	no code in mainline yet, planned for the future
  Linux kernel plat directory:
	no code in mainline yet, planned for the future

Storage family
--------------

  Armada SP:
	- 88RC1580

  Product infos:
	https://web.archive.org/web/20191129073953/http://www.marvell.com/storage/armada-sp/

  Core:
	Sheeva ARMv7 compatible Quad-core PJ4C

  (not supported in upstream Linux kernel)

Dove family (application processor)
-----------------------------------

  Flavors:
        - 88AP510 a.k.a Armada 510

   Product Brief:
	https://web.archive.org/web/20111102020643/http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf

   Hardware Spec:
	https://web.archive.org/web/20160428160231/http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Hardware-Spec.pdf

  Functional Spec:
	https://web.archive.org/web/20120130172443/http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf

  Homepage:
	https://web.archive.org/web/20160822232651/http://www.marvell.com/application-processors/armada-500/

  Core:
	ARMv7 compatible

  Directory:
	- arch/arm/mach-mvebu (DT enabled platforms)
        - arch/arm/mach-dove (non-DT enabled platforms)

PXA 2xx/3xx/93x/95x family
--------------------------

  Flavors:
        - PXA21x, PXA25x, PXA26x
             - Application processor only
             - Core: ARMv5 XScale1 core
        - PXA270, PXA271, PXA272
             - Product Brief         : https://web.archive.org/web/20150927135510/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
             - Design guide          : https://web.archive.org/web/20120111181937/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
             - Developers manual     : https://web.archive.org/web/20150927164805/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_dev_man.pdf
             - Specification         : https://web.archive.org/web/20140211221535/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
             - Specification update  : https://web.archive.org/web/20120111104906/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
             - Application processor only
             - Core: ARMv5 XScale2 core
        - PXA300, PXA310, PXA320
             - PXA 300 Product Brief : https://web.archive.org/web/20120111121203/http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
             - PXA 310 Product Brief : https://web.archive.org/web/20120111104515/http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
             - PXA 320 Product Brief : https://web.archive.org/web/20121021182826/http://www.marvell.com/application-processors/pxa-family/assets/PXA320_PB_R4.pdf
             - Design guide          : https://web.archive.org/web/20130727144625/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Design_Guide.pdf
             - Developers manual     : https://web.archive.org/web/20130727144605/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip
             - Specifications        : https://web.archive.org/web/20130727144559/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_EMTS.pdf
             - Specification Update  : https://web.archive.org/web/20150927183411/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
             - Reference Manual      : https://web.archive.org/web/20120111103844/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf
             - Application processor only
             - Core: ARMv5 XScale3 core
        - PXA930, PXA935
             - Application processor with Communication processor
             - Core: ARMv5 XScale3 core
        - PXA955
             - Application processor with Communication processor
             - Core: ARMv7 compatible Sheeva PJ4 core

   Comments:

    * This line of SoCs originates from the XScale family developed by
      Intel and acquired by Marvell in ~2006. The PXA21x, PXA25x,
      PXA26x, PXA27x, PXA3xx and PXA93x were developed by Intel, while
      the later PXA95x were developed by Marvell.

    * Due to their XScale origin, these SoCs have virtually nothing in
      common with the other (Kirkwood, Dove, etc.) families of Marvell
      SoCs, except with the MMP/MMP2 family of SoCs.

   Linux kernel mach directory:
	arch/arm/mach-pxa

MMP/MMP2/MMP3 family (communication processor)
----------------------------------------------

   Flavors:
        - PXA168, a.k.a Armada 168
             - Homepage             : https://web.archive.org/web/20110926014256/http://www.marvell.com/application-processors/armada-100/armada-168.jsp
             - Product brief        : https://web.archive.org/web/20111102030100/http://www.marvell.com/application-processors/armada-100/assets/pxa_168_pb.pdf
             - Hardware manual      : https://web.archive.org/web/20160428165359/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_datasheet.pdf
             - Software manual      : https://web.archive.org/web/20160428154454/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_software_manual.pdf
             - Specification update : https://web.archive.org/web/20150927160338/http://www.marvell.com/application-processors/armada-100/assets/ARMADA16x_Spec_update.pdf
             - Boot ROM manual      : https://web.archive.org/web/20130727205559/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
             - App node package     : https://web.archive.org/web/20141005090706/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf
             - Application processor only
             - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
        - PXA910/PXA920
             - Homepage             : https://web.archive.org/web/20150928121236/http://www.marvell.com/communication-processors/pxa910/
             - Product Brief        : https://archive.org/download/marvell-pxa910-pb/Marvell_PXA910_Platform-001_PB.pdf
             - Application processor with Communication processor
             - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
        - PXA688, a.k.a. MMP2, a.k.a Armada 610 (OLPC XO-1.75)
             - Product Brief        : https://web.archive.org/web/20111102023255/http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf
             - Application processor only
             - Core: ARMv7 compatible Sheeva PJ4 88sv581x core
	- PXA2128, a.k.a. MMP3, a.k.a Armada 620 (OLPC XO-4)
	     - Product Brief	    : https://web.archive.org/web/20120824055155/http://www.marvell.com/application-processors/armada/pxa2128/assets/Marvell-ARMADA-PXA2128-SoC-PB.pdf
	     - Application processor only
	     - Core: Dual-core ARMv7 compatible Sheeva PJ4C core
	- PXA960/PXA968/PXA978 (Linux support not upstream)
	     - Application processor with Communication Processor
	     - Core: ARMv7 compatible Sheeva PJ4 core
	- PXA986/PXA988 (Linux support not upstream)
	     - Application processor with Communication Processor
	     - Core: Dual-core ARMv7 compatible Sheeva PJ4B-MP core
	- PXA1088/PXA1920 (Linux support not upstream)
	     - Application processor with Communication Processor
	     - Core: quad-core ARMv7 Cortex-A7
	- PXA1908/PXA1928/PXA1936
	     - Application processor with Communication Processor
	     - Core: multi-core ARMv8 Cortex-A53

   Comments:

    * This line of SoCs originates from the XScale family developed by
      Intel and acquired by Marvell in ~2006. All the processors of
      this MMP/MMP2 family were developed by Marvell.

    * Due to their XScale origin, these SoCs have virtually nothing in
      common with the other (Kirkwood, Dove, etc.) families of Marvell
      SoCs, except with the PXA family of SoCs listed above.

   Linux kernel mach directory:
	arch/arm/mach-mmp

Berlin family (Multimedia Solutions)
-------------------------------------

  - Flavors:
	- 88DE3010, Armada 1000 (no Linux support)
		- Core:		Marvell PJ1 (ARMv5TE), Dual-core
		- Product Brief:	https://web.archive.org/web/20131103162620/http://www.marvell.com/digital-entertainment/assets/armada_1000_pb.pdf
	- 88DE3005, Armada 1500 Mini
		- Design name:	BG2CD
		- Core:		ARM Cortex-A9, PL310 L2CC
	- 88DE3006, Armada 1500 Mini Plus
		- Design name:	BG2CDP
		- Core:		Dual Core ARM Cortex-A7
	- 88DE3100, Armada 1500
		- Design name:	BG2
		- Core:		Marvell PJ4B-MP (ARMv7), Tauros3 L2CC
	- 88DE3114, Armada 1500 Pro
		- Design name:	BG2Q
		- Core:		Quad Core ARM Cortex-A9, PL310 L2CC
	- 88DE3214, Armada 1500 Pro 4K
		- Design name:	BG3
		- Core:		ARM Cortex-A15, CA15 integrated L2CC
	- 88DE3218, ARMADA 1500 Ultra
		- Core:		ARM Cortex-A53

  Homepage: https://www.synaptics.com/products/multimedia-solutions
  Directory: arch/arm/mach-berlin

  Comments:

   * This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
     with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...).

   * The Berlin family was acquired by Synaptics from Marvell in 2017.

CPU Cores
---------

The XScale cores were designed by Intel, and shipped by Marvell in the older
PXA processors. Feroceon is a Marvell designed core that developed in-house,
and that evolved into Sheeva. The XScale and Feroceon cores were phased out
over time and replaced with Sheeva cores in later products, which subsequently
got replaced with licensed ARM Cortex-A cores.

  XScale 1
	CPUID 0x69052xxx
	ARMv5, iWMMXt
  XScale 2
	CPUID 0x69054xxx
	ARMv5, iWMMXt
  XScale 3
	CPUID 0x69056xxx or 0x69056xxx
	ARMv5, iWMMXt
  Feroceon-1850 88fr331 "Mohawk"
	CPUID 0x5615331x or 0x41xx926x
	ARMv5TE, single issue
  Feroceon-2850 88fr531-vd "Jolteon"
	CPUID 0x5605531x or 0x41xx926x
	ARMv5TE, VFP, dual-issue
  Feroceon 88fr571-vd "Jolteon"
	CPUID 0x5615571x
	ARMv5TE, VFP, dual-issue
  Feroceon 88fr131 "Mohawk-D"
	CPUID 0x5625131x
	ARMv5TE, single-issue in-order
  Sheeva PJ1 88sv331 "Mohawk"
	CPUID 0x561584xx
	ARMv5, single-issue iWMMXt v2
  Sheeva PJ4 88sv581x "Flareon"
	CPUID 0x560f581x
	ARMv7, idivt, optional iWMMXt v2
  Sheeva PJ4B 88sv581x
	CPUID 0x561f581x
	ARMv7, idivt, optional iWMMXt v2
  Sheeva PJ4B-MP / PJ4C
	CPUID 0x562f584x
	ARMv7, idivt/idiva, LPAE, optional iWMMXt v2 and/or NEON

Long-term plans
---------------

 * Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ into the
   mach-mvebu/ to support all SoCs from the Marvell EBU (Engineering
   Business Unit) in a single mach-<foo> directory. The plat-orion/
   would therefore disappear.

Credits
-------

- Maen Suleiman <maen@marvell.com>
- Lior Amsalem <alior@marvell.com>
- Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- Andrew Lunn <andrew@lunn.ch>
- Nicolas Pitre <nico@fluxnic.net>
- Eric Miao <eric.y.miao@gmail.com>


code:
================
Memory alignment
================

Too many problems popped up because of unnoticed misaligned memory access in
kernel code lately.  Therefore the alignment fixup is now unconditionally
configured in for SA11x0 based targets.  According to Alan Cox, this is a
bad idea to configure it out, but Russell King has some good reasons for
doing so on some f***ed up ARM architectures like the EBSA110.  However
this is not the case on many design I'm aware of, like all SA11x0 based
ones.

Of course this is a bad idea to rely on the alignment trap to perform
unaligned memory access in general.  If those access are predictable, you
are better to use the macros provided by include/asm/unaligned.h.  The
alignment trap can fixup misaligned access for the exception cases, but at
a high performance cost.  It better be rare.

Now for user space applications, it is possible to configure the alignment
trap to SIGBUS any code performing unaligned access (good for debugging bad
code), or even fixup the access by software like for kernel code.  The later
mode isn't recommended for performance reasons (just think about the
floating point emulation that works about the same way).  Fix your code
instead!

Please note that randomly changing the behaviour without good thought is
real bad - it changes the behaviour of all unaligned instructions in user
space, and might cause programs to fail unexpectedly.

To change the alignment trap behavior, simply echo a number into
/proc/cpu/alignment.  The number is made up from various bits:

===		========================================================
bit		behavior when set
===		========================================================
0		A user process performing an unaligned memory access
		will cause the kernel to print a message indicating
		process name, pid, pc, instruction, address, and the
		fault code.

1		The kernel will attempt to fix up the user process
		performing the unaligned access.  This is of course
		slow (think about the floating point emulator) and
		not recommended for production use.

2		The kernel will send a SIGBUS signal to the user process
		performing the unaligned access.
===		========================================================

Note that not all combinations are supported - only values 0 through 5.
(6 and 7 don't make sense).

For example, the following will turn on the warnings, but without
fixing up or sending SIGBUS signals::

	echo 1 > /proc/cpu/alignment

You can also read the content of the same file to get statistical
information on unaligned access occurrences plus the current mode of
operation for user space code.

Nicolas Pitre, Mar 13, 2001.  Modified Russell King, Nov 30, 2001.

repo_name: angery/linux


code:
=================================
Kernel Memory Layout on ARM Linux
=================================

		Russell King <rmk@arm.linux.org.uk>

		     November 17, 2005 (2.6.15)

This document describes the virtual memory layout which the Linux
kernel uses for ARM processors.  It indicates which regions are
free for platforms to use, and which are used by generic code.

The ARM CPU is capable of addressing a maximum of 4GB virtual memory
space, and this must be shared between user space processes, the
kernel, and hardware devices.

As the ARM architecture matures, it becomes necessary to reserve
certain regions of VM space for use for new facilities; therefore
this document may reserve more VM space over time.

=============== =============== ===============================================
Start		End		Use
=============== =============== ===============================================
ffff8000	ffffffff	copy_user_page / clear_user_page use.
				For SA11xx and Xscale, this is used to
				setup a minicache mapping.

ffff4000	ffffffff	cache aliasing on ARMv6 and later CPUs.

ffff1000	ffff7fff	Reserved.
				Platforms must not use this address range.

ffff0000	ffff0fff	CPU vector page.
				The CPU vectors are mapped here if the
				CPU supports vector relocation (control
				register V bit.)

fffe0000	fffeffff	XScale cache flush area.  This is used
				in proc-xscale.S to flush the whole data
				cache. (XScale does not have TCM.)

fffe8000	fffeffff	DTCM mapping area for platforms with
				DTCM mounted inside the CPU.

fffe0000	fffe7fff	ITCM mapping area for platforms with
				ITCM mounted inside the CPU.

ffc80000	ffefffff	Fixmap mapping region.  Addresses provided
				by fix_to_virt() will be located here.

ffc00000	ffc7ffff	Guard region

ff800000	ffbfffff	Permanent, fixed read-only mapping of the
				firmware provided DT blob

fee00000	feffffff	Mapping of PCI I/O space. This is a static
				mapping within the vmalloc space.

VMALLOC_START	VMALLOC_END-1	vmalloc() / ioremap() space.
				Memory returned by vmalloc/ioremap will
				be dynamically placed in this region.
				Machine specific static mappings are also
				located here through iotable_init().
				VMALLOC_START is based upon the value
				of the high_memory variable, and VMALLOC_END
				is equal to 0xff800000.

PAGE_OFFSET	high_memory-1	Kernel direct-mapped RAM region.
				This maps the platforms RAM, and typically
				maps all platform RAM in a 1:1 relationship.

PKMAP_BASE	PAGE_OFFSET-1	Permanent kernel mappings
				One way of mapping HIGHMEM pages into kernel
				space.

MODULES_VADDR	MODULES_END-1	Kernel module space
				Kernel modules inserted via insmod are
				placed here using dynamic mappings.

TASK_SIZE	MODULES_VADDR-1	KASAn shadow memory when KASan is in use.
				The range from MODULES_VADDR to the top
				of the memory is shadowed here with 1 bit
				per byte of memory.

00001000	TASK_SIZE-1	User space mappings
				Per-thread mappings are placed here via
				the mmap() system call.

00000000	00000fff	CPU vector page / null pointer trap
				CPUs which do not support vector remapping
				place their vector page here.  NULL pointer
				dereferences by both the kernel and user
				space are also caught via this mapping.
=============== =============== ===============================================

Please note that mappings which collide with the above areas may result
in a non-bootable kernel, or may cause the kernel to (eventually) panic
at run time.

Since future CPUs may impact the kernel mapping layout, user programs
must not access any memory which is not mapped inside their 0x0001000
to TASK_SIZE address range.  If they wish to access these areas, they
must set up their own mappings using open() and mmap().


code:
=============================
ARM Microchip SoCs (aka AT91)
=============================

Introduction
------------
This document gives useful information about the ARM Microchip SoCs that are
currently supported in Linux Mainline (you know, the one on kernel.org).

It is important to note that the Microchip (previously Atmel) ARM-based MPU
product line is historically named "AT91" or "at91" throughout the Linux kernel
development process even if this product prefix has completely disappeared from
the official Microchip product name. Anyway, files, directories, git trees,
git branches/tags and email subject always contain this "at91" sub-string.

AT91 SoCs
---------
Documentation and detailed datasheet for each product are available on
the Microchip website: http://www.microchip.com.

  Flavors:
    * ARM 920 based SoC
      - at91rm9200

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-1768-32-bit-ARM920T-Embedded-Microprocessor-AT91RM9200_Datasheet.pdf

    * ARM 926 based SoCs
      - at91sam9260

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6221-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9260_Datasheet.pdf

      - at91sam9xe

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6254-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9XE_Datasheet.pdf

      - at91sam9261

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6062-ARM926EJ-S-Microprocessor-SAM9261_Datasheet.pdf

      - at91sam9263

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6249-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9263_Datasheet.pdf

      - at91sam9rl

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/doc6289.pdf

      - at91sam9g20

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001516A.pdf

      - at91sam9g45 family
        - at91sam9g45
        - at91sam9g46
        - at91sam9m10
        - at91sam9m11 (device superset)

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6437-32-bit-ARM926-Embedded-Microprocessor-SAM9M11_Datasheet.pdf

      - at91sam9x5 family (aka "The 5 series")
        - at91sam9g15
        - at91sam9g25
        - at91sam9g35
        - at91sam9x25
        - at91sam9x35

          * Datasheet (can be considered as covering the whole family)

          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11055-32-bit-ARM926EJ-S-Microcontroller-SAM9X35_Datasheet.pdf

      - at91sam9n12

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001517A.pdf

      - sam9x60

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/SAM9X60-Data-Sheet-DS60001579A.pdf

    * ARM Cortex-A5 based SoCs
      - sama5d3 family

        - sama5d31
        - sama5d33
        - sama5d34
        - sama5d35
        - sama5d36 (device superset)

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet_B.pdf

    * ARM Cortex-A5 + NEON based SoCs
      - sama5d4 family

        - sama5d41
        - sama5d42
        - sama5d43
        - sama5d44 (device superset)

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/60001525A.pdf

      - sama5d2 family

        - sama5d21
        - sama5d22
        - sama5d23
        - sama5d24
        - sama5d26
        - sama5d27 (device superset)
        - sama5d28 (device superset + environmental monitors)

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001476B.pdf

    * ARM Cortex-A7 based SoCs
      - sama7g5 family

        - sama7g51
        - sama7g52
        - sama7g53
        - sama7g54 (device superset)

          * Datasheet

          Coming soon

      - lan966 family
        - lan9662
        - lan9668

          * Datasheet

          Coming soon

    * ARM Cortex-M7 MCUs
      - sams70 family

        - sams70j19
        - sams70j20
        - sams70j21
        - sams70n19
        - sams70n20
        - sams70n21
        - sams70q19
        - sams70q20
        - sams70q21

      - samv70 family

        - samv70j19
        - samv70j20
        - samv70n19
        - samv70n20
        - samv70q19
        - samv70q20

      - samv71 family

        - samv71j19
        - samv71j20
        - samv71j21
        - samv71n19
        - samv71n20
        - samv71n21
        - samv71q19
        - samv71q20
        - samv71q21

          * Datasheet

          http://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70-S70-V70-V71-Family-Data-Sheet-DS60001527D.pdf

Linux kernel information
------------------------
Linux kernel mach directory: arch/arm/mach-at91
MAINTAINERS entry is: "ARM/Microchip (AT91) SoC support"

Device Tree for AT91 SoCs and boards
------------------------------------
All AT91 SoCs are converted to Device Tree. Since Linux 3.19, these products
must use this method to boot the Linux kernel.

Work In Progress statement:
Device Tree files and Device Tree bindings that apply to AT91 SoCs and boards are
considered as "Unstable". To be completely clear, any at91 binding can change at
any time. So, be sure to use a Device Tree Binary and a Kernel Image generated from
the same source tree.
Please refer to the Documentation/devicetree/bindings/ABI.rst file for a
definition of a "Stable" binding/ABI.
This statement will be removed by AT91 MAINTAINERS when appropriate.

Naming conventions and best practice:

- SoCs Device Tree Source Include files are named after the official name of
  the product (at91sam9g20.dtsi or sama5d33.dtsi for instance).
- Device Tree Source Include files (.dtsi) are used to collect common nodes that can be
  shared across SoCs or boards (sama5d3.dtsi or at91sam9x5cm.dtsi for instance).
  When collecting nodes for a particular peripheral or topic, the identifier have to
  be placed at the end of the file name, separated with a "_" (at91sam9x5_can.dtsi
  or sama5d3_gmac.dtsi for example).
- board Device Tree Source files (.dts) are prefixed by the string "at91-" so
  that they can be identified easily. Note that some files are historical exceptions
  to this rule (sama5d3[13456]ek.dts, usb_a9g20.dts or animeo_ip.dts for example).


code:
================================
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
======= ======= ===========


code:
.. SPDX-License-Identifier: GPL-2.0

===================================
NetWinder's floating point emulator
===================================

.. toctree::
   :maxdepth: 1

   nwfpe
   netwinder-fpe
   notes
   todo


code:
=============
Current State
=============

The following describes the current state of the NetWinder's floating point
emulator.

In the following nomenclature is used to describe the floating point
instructions.  It follows the conventions in the ARM manual.

::

  <S|D|E> = <single|double|extended>, no default
  {P|M|Z} = {round to +infinity,round to -infinity,round to zero},
            default = round to nearest

Note: items enclosed in {} are optional.

Floating Point Coprocessor Data Transfer Instructions (CPDT)
------------------------------------------------------------

LDF/STF - load and store floating

<LDF|STF>{cond}<S|D|E> Fd, Rn
<LDF|STF>{cond}<S|D|E> Fd, [Rn, #<expression>]{!}
<LDF|STF>{cond}<S|D|E> Fd, [Rn], #<expression>

These instructions are fully implemented.

LFM/SFM - load and store multiple floating

Form 1 syntax:
<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn]
<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn, #<expression>]{!}
<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn], #<expression>

Form 2 syntax:
<LFM|SFM>{cond}<FD,EA> Fd, <count>, [Rn]{!}

These instructions are fully implemented.  They store/load three words
for each floating point register into the memory location given in the
instruction.  The format in memory is unlikely to be compatible with
other implementations, in particular the actual hardware.  Specific
mention of this is made in the ARM manuals.

Floating Point Coprocessor Register Transfer Instructions (CPRT)
----------------------------------------------------------------

Conversions, read/write status/control register instructions

FLT{cond}<S,D,E>{P,M,Z} Fn, Rd          Convert integer to floating point
FIX{cond}{P,M,Z} Rd, Fn                 Convert floating point to integer
WFS{cond} Rd                            Write floating point status register
RFS{cond} Rd                            Read floating point status register
WFC{cond} Rd                            Write floating point control register
RFC{cond} Rd                            Read floating point control register

FLT/FIX are fully implemented.

RFS/WFS are fully implemented.

RFC/WFC are fully implemented.  RFC/WFC are supervisor only instructions, and
presently check the CPU mode, and do an invalid instruction trap if not called
from supervisor mode.

Compare instructions

CMF{cond} Fn, Fm        Compare floating
CMFE{cond} Fn, Fm       Compare floating with exception
CNF{cond} Fn, Fm        Compare negated floating
CNFE{cond} Fn, Fm       Compare negated floating with exception

These are fully implemented.

Floating Point Coprocessor Data Instructions (CPDT)
---------------------------------------------------

Dyadic operations:

ADF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - add
SUF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - subtract
RSF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse subtract
MUF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - multiply
DVF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - divide
RDV{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse divide

These are fully implemented.

FML{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast multiply
FDV{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast divide
FRD{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast reverse divide

These are fully implemented as well.  They use the same algorithm as the
non-fast versions.  Hence, in this implementation their performance is
equivalent to the MUF/DVF/RDV instructions.  This is acceptable according
to the ARM manual.  The manual notes these are defined only for single
operands, on the actual FPA11 hardware they do not work for double or
extended precision operands.  The emulator currently does not check
the requested permissions conditions, and performs the requested operation.

RMF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - IEEE remainder

This is fully implemented.

Monadic operations:

MVF{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - move
MNF{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - move negated

These are fully implemented.

ABS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - absolute value
SQT{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - square root
RND{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - round

These are fully implemented.

URD{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - unnormalized round
NRM{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - normalize

These are implemented.  URD is implemented using the same code as the RND
instruction.  Since URD cannot return a unnormalized number, NRM becomes
a NOP.

Library calls:

POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power
RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power
POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2)

LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10
LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e
EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent
SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine
COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine
TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent
ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine
ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine
ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent

These are not implemented.  They are not currently issued by the compiler,
and are handled by routines in libc.  These are not implemented by the FPA11
hardware, but are handled by the floating point support code.  They should
be implemented in future versions.

Signalling:

Signals are implemented.  However current ELF kernels produced by Rebel.com
have a bug in them that prevents the module from generating a SIGFPE.  This
is caused by a failure to alias fp_current to the kernel variable
current_set[0] correctly.

The kernel provided with this distribution (vmlinux-nwfpe-0.93) contains
a fix for this problem and also incorporates the current version of the
emulator directly.  It is possible to run with no floating point module
loaded with this kernel.  It is provided as a demonstration of the
technology and for those who want to do floating point work that depends
on signals.  It is not strictly necessary to use the module.

A module (either the one provided by Russell King, or the one in this
distribution) can be loaded to replace the functionality of the emulator
built into the kernel.


code:
Notes
=====

There seems to be a problem with exp(double) and our emulator.  I haven't
been able to track it down yet.  This does not occur with the emulator
supplied by Russell King.

I also found one oddity in the emulator.  I don't think it is serious but
will point it out.  The ARM calling conventions require floating point
registers f4-f7 to be preserved over a function call.  The compiler quite
often uses an stfe instruction to save f4 on the stack upon entry to a
function, and an ldfe instruction to restore it before returning.

I was looking at some code, that calculated a double result, stored it in f4
then made a function call. Upon return from the function call the number in
f4 had been converted to an extended value in the emulator.

This is a side effect of the stfe instruction.  The double in f4 had to be
converted to extended, then stored.  If an lfm/sfm combination had been used,
then no conversion would occur.  This has performance considerations.  The
result from the function call and f4 were used in a multiplication.  If the
emulator sees a multiply of a double and extended, it promotes the double to
extended, then does the multiply in extended precision.

This code will cause this problem:

double x, y, z;
z = log(x)/log(y);

The result of log(x) (a double) will be calculated, returned in f0, then
moved to f4 to preserve it over the log(y) call.  The division will be done
in extended precision, due to the stfe instruction used to save f4 in log(y).


code:
Introduction
============

This directory contains the version 0.92 test release of the NetWinder
Floating Point Emulator.

The majority of the code was written by me, Scott Bambrough It is
written in C, with a small number of routines in inline assembler
where required.  It was written quickly, with a goal of implementing a
working version of all the floating point instructions the compiler
emits as the first target.  I have attempted to be as optimal as
possible, but there remains much room for improvement.

I have attempted to make the emulator as portable as possible.  One of
the problems is with leading underscores on kernel symbols.  Elf
kernels have no leading underscores, a.out compiled kernels do.  I
have attempted to use the C_SYMBOL_NAME macro wherever this may be
important.

Another choice I made was in the file structure.  I have attempted to
contain all operating system specific code in one module (fpmodule.*).
All the other files contain emulator specific code.  This should allow
others to port the emulator to NetBSD for instance relatively easily.

The floating point operations are based on SoftFloat Release 2, by
John Hauser.  SoftFloat is a software implementation of floating-point
that conforms to the IEC/IEEE Standard for Binary Floating-point
Arithmetic.  As many as four formats are supported: single precision,
double precision, extended double precision, and quadruple precision.
All operations required by the standard are implemented, except for
conversions to and from decimal.  We use only the single precision,
double precision and extended double precision formats.  The port of
SoftFloat to the ARM was done by Phil Blundell, based on an earlier
port of SoftFloat version 1 by Neil Carson for NetBSD/arm32.

The file README.FPE contains a description of what has been implemented
so far in the emulator.  The file TODO contains a information on what
remains to be done, and other ideas for the emulator.

Bug reports, comments, suggestions should be directed to me at
<scottb@netwinder.org>.  General reports of "this program doesn't
work correctly when your emulator is installed" are useful for
determining that bugs still exist; but are virtually useless when
attempting to isolate the problem.  Please report them, but don't
expect quick action.  Bugs still exist.  The problem remains in isolating
which instruction contains the bug.  Small programs illustrating a specific
problem are a godsend.

Legal Notices
-------------

The NetWinder Floating Point Emulator is free software.  Everything Rebel.com
has written is provided under the GNU GPL.  See the file COPYING for copying
conditions.  Excluded from the above is the SoftFloat code.  John Hauser's
legal notice for SoftFloat is included below.

-------------------------------------------------------------------------------

SoftFloat Legal Notice

SoftFloat was written by John R. Hauser.  This work was made possible in
part by the International Computer Science Institute, located at Suite 600,
1947 Center Street, Berkeley, California 94704.  Funding was partially
provided by the National Science Foundation under grant MIP-9311980.  The
original version of this code was written as part of a project to build
a fixed-point vector processor in collaboration with the University of
California at Berkeley, overseen by Profs. Nelson Morgan and John Wawrzynek.

THIS SOFTWARE IS DISTRIBUTED AS IS, FOR FREE.  Although reasonable effort
has been made to avoid it, THIS SOFTWARE MAY CONTAIN FAULTS THAT WILL AT
TIMES RESULT IN INCORRECT BEHAVIOR.  USE OF THIS SOFTWARE IS RESTRICTED TO
PERSONS AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ANY
AND ALL LOSSES, COSTS, OR OTHER PROBLEMS ARISING FROM ITS USE.
-------------------------------------------------------------------------------


code:
TODO LIST
=========

::

  POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power
  RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power
  POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2)

  LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10
  LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e
  EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent
  SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine
  COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine
  TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent
  ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine
  ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine
  ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent

These are not implemented.  They are not currently issued by the compiler,
and are handled by routines in libc.  These are not implemented by the FPA11
hardware, but are handled by the floating point support code.  They should
be implemented in future versions.

There are a couple of ways to approach the implementation of these.  One
method would be to use accurate table methods for these routines.  I have
a couple of papers by S. Gal from IBM's research labs in Haifa, Israel that
seem to promise extreme accuracy (in the order of 99.8%) and reasonable speed.
These methods are used in GLIBC for some of the transcendental functions.

Another approach, which I know little about is CORDIC.  This stands for
Coordinate Rotation Digital Computer, and is a method of computing
transcendental functions using mostly shifts and adds and a few
multiplications and divisions.  The ARM excels at shifts and adds,
so such a method could be promising, but requires more research to
determine if it is feasible.

Rounding Methods
----------------

The IEEE standard defines 4 rounding modes.  Round to nearest is the
default, but rounding to + or - infinity or round to zero are also allowed.
Many architectures allow the rounding mode to be specified by modifying bits
in a control register.  Not so with the ARM FPA11 architecture.  To change
the rounding mode one must specify it with each instruction.

This has made porting some benchmarks difficult.  It is possible to
introduce such a capability into the emulator.  The FPCR contains
bits describing the rounding mode.  The emulator could be altered to
examine a flag, which if set forced it to ignore the rounding mode in
the instruction, and use the mode specified in the bits in the FPCR.

This would require a method of getting/setting the flag, and the bits
in the FPCR.  This requires a kernel call in ArmLinux, as WFC/RFC are
supervisor only instructions.  If anyone has any ideas or comments I
would like to hear them.

NOTE:
 pulled out from some docs on ARM floating point, specifically
 for the Acorn FPE, but not limited to it:

 The floating point control register (FPCR) may only be present in some
 implementations: it is there to control the hardware in an implementation-
 specific manner, for example to disable the floating point system.  The user
 mode of the ARM is not permitted to use this register (since the right is
 reserved to alter it between implementations) and the WFC and RFC
 instructions will trap if tried in user mode.

 Hence, the answer is yes, you could do this, but then you will run a high
 risk of becoming isolated if and when hardware FP emulation comes out

		-- Russell.


code:
=========================
OMAP2/3 Display Subsystem
=========================

This is an almost total rewrite of the OMAP FB driver in drivers/video/omap
(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI,
TV-out and multiple display support, but there are lots of small improvements
also.

The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB,
panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live
currently side by side, you can choose which one to use.

Features
--------

Working and tested features include:

- MIPI DPI (parallel) output
- MIPI DSI output in command mode
- MIPI DBI (RFBI) output
- SDI output
- TV output
- All pieces can be compiled as a module or inside kernel
- Use DISPC to update any of the outputs
- Use CPU to update RFBI or DSI output
- OMAP DISPC planes
- RGB16, RGB24 packed, RGB24 unpacked
- YUV2, UYVY
- Scaling
- Adjusting DSS FCK to find a good pixel clock
- Use DSI DPLL to create DSS FCK

Tested boards include:
- OMAP3 SDP board
- Beagle board
- N810

omapdss driver
--------------

The DSS driver does not itself have any support for Linux framebuffer, V4L or
such like the current ones, but it has an internal kernel API that upper level
drivers can use.

The DSS driver models OMAP's overlays, overlay managers and displays in a
flexible way to enable non-common multi-display configuration. In addition to
modelling the hardware overlays, omapdss supports virtual overlays and overlay
managers. These can be used when updating a display with CPU or system DMA.

omapdss driver support for audio
--------------------------------
There exist several display technologies and standards that support audio as
well. Hence, it is relevant to update the DSS device driver to provide an audio
interface that may be used by an audio driver or any other driver interested in
the functionality.

The audio_enable function is intended to prepare the relevant
IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
some IP, enabling companion chips, etc). It is intended to be called before
audio_start. The audio_disable function performs the reverse operation and is
intended to be called after audio_stop.

While a given DSS device driver may support audio, it is possible that for
certain configurations audio is not supported (e.g., an HDMI display using a
VESA video timing). The audio_supported function is intended to query whether
the current configuration of the display supports audio.

The audio_config function is intended to configure all the relevant audio
parameters of the display. In order to make the function independent of any
specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
is to contain all the required parameters for audio configuration. At the
moment, such structure contains pointers to IEC-60958 channel status word
and CEA-861 audio infoframe structures. This should be enough to support
HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.

The audio_enable/disable, audio_config and audio_supported functions could be
implemented as functions that may sleep. Hence, they should not be called
while holding a spinlock or a readlock.

The audio_start/audio_stop function is intended to effectively start/stop audio
playback after the configuration has taken place. These functions are designed
to be used in an atomic context. Hence, audio_start should return quickly and be
called only after all the needed resources for audio playback (audio FIFOs,
DMA channels, companion chips, etc) have been enabled to begin data transfers.
audio_stop is designed to only stop the audio transfers. The resources used
for playback are released using audio_disable.

The enum omap_dss_audio_state may be used to help the implementations of
the interface to keep track of the audio state. The initial state is _DISABLED;
then, the state transitions to _CONFIGURED, and then, when it is ready to
play audio, to _ENABLED. The state _PLAYING is used when the audio is being
rendered.

Panel and controller drivers
----------------------------

The drivers implement panel or controller specific functionality and are not
usually visible to users except through omapfb driver.  They register
themselves to the DSS driver.

omapfb driver
-------------

The omapfb driver implements arbitrary number of standard linux framebuffers.
These framebuffers can be routed flexibly to any overlays, thus allowing very
dynamic display architecture.

The driver exports some omapfb specific ioctls, which are compatible with the
ioctls in the old driver.

The rest of the non standard features are exported via sysfs. Whether the final
implementation will use sysfs, or ioctls, is still open.

V4L2 drivers
------------

V4L2 is being implemented in TI.

From omapdss point of view the V4L2 drivers should be similar to framebuffer
driver.

Architecture
--------------------

Some clarification what the different components do:

    - Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the
      pixel data for the image. Framebuffer has width and height and color
      depth.
    - Overlay defines where the pixels are read from and where they go on the
      screen. The overlay may be smaller than framebuffer, thus displaying only
      part of the framebuffer. The position of the overlay may be changed if
      the overlay is smaller than the display.
    - Overlay manager combines the overlays in to one image and feeds them to
      display.
    - Display is the actual physical display device.

A framebuffer can be connected to multiple overlays to show the same pixel data
on all of the overlays. Note that in this case the overlay input sizes must be
the same, but, in case of video overlays, the output size can be different. Any
framebuffer can be connected to any overlay.

An overlay can be connected to one overlay manager. Also DISPC overlays can be
connected only to DISPC overlay managers, and virtual overlays can be only
connected to virtual overlays.

An overlay manager can be connected to one display. There are certain
restrictions which kinds of displays an overlay manager can be connected:

    - DISPC TV overlay manager can be only connected to TV display.
    - Virtual overlay managers can only be connected to DBI or DSI displays.
    - DISPC LCD overlay manager can be connected to all displays, except TV
      display.

Sysfs
-----
The sysfs interface is mainly used for testing. I don't think sysfs
interface is the best for this in the final version, but I don't quite know
what would be the best interfaces for these things.

The sysfs interface is divided to two parts: DSS and FB.

/sys/class/graphics/fb? directory:
mirror		0=off, 1=on
rotate		Rotation 0-3 for 0, 90, 180, 270 degrees
rotate_type	0 = DMA rotation, 1 = VRFB rotation
overlays	List of overlay numbers to which framebuffer pixels go
phys_addr	Physical address of the framebuffer
virt_addr	Virtual address of the framebuffer
size		Size of the framebuffer

/sys/devices/platform/omapdss/overlay? directory:
enabled		0=off, 1=on
input_size	width,height (ie. the framebuffer size)
manager		Destination overlay manager name
name
output_size	width,height
position	x,y
screen_width	width
global_alpha   	global alpha 0-255 0=transparent 255=opaque

/sys/devices/platform/omapdss/manager? directory:
display				Destination display
name
alpha_blending_enabled		0=off, 1=on
trans_key_enabled		0=off, 1=on
trans_key_type			gfx-destination, video-source
trans_key_value			transparency color key (RGB24)
default_color			default background color (RGB24)

/sys/devices/platform/omapdss/display? directory:

=============== =============================================================
ctrl_name	Controller name
mirror		0=off, 1=on
update_mode	0=off, 1=auto, 2=manual
enabled		0=off, 1=on
name
rotate		Rotation 0-3 for 0, 90, 180, 270 degrees
timings		Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)
		When writing, two special timings are accepted for tv-out:
		"pal" and "ntsc"
panel_name
tear_elim	Tearing elimination 0=off, 1=on
output_type	Output type (video encoder only): "composite" or "svideo"
=============== =============================================================

There are also some debugfs files at <debugfs>/omapdss/ which show information
about clocks and registers.

Examples
--------

The following definitions have been made for the examples below::

	ovl0=/sys/devices/platform/omapdss/overlay0
	ovl1=/sys/devices/platform/omapdss/overlay1
	ovl2=/sys/devices/platform/omapdss/overlay2

	mgr0=/sys/devices/platform/omapdss/manager0
	mgr1=/sys/devices/platform/omapdss/manager1

	lcd=/sys/devices/platform/omapdss/display0
	dvi=/sys/devices/platform/omapdss/display1
	tv=/sys/devices/platform/omapdss/display2

	fb0=/sys/class/graphics/fb0
	fb1=/sys/class/graphics/fb1
	fb2=/sys/class/graphics/fb2

Default setup on OMAP3 SDP
--------------------------

Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI
and TV-out are not in use. The columns from left to right are:
framebuffers, overlays, overlay managers, displays. Framebuffers are
handled by omapfb, and the rest by the DSS::

	FB0 --- GFX  -\            DVI
	FB1 --- VID1 --+- LCD ---- LCD
	FB2 --- VID2 -/   TV ----- TV

Example: Switch from LCD to DVI
-------------------------------

::

	w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1`
	h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1`

	echo "0" > $lcd/enabled
	echo "" > $mgr0/display
	fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h
	# at this point you have to switch the dvi/lcd dip-switch from the omap board
	echo "dvi" > $mgr0/display
	echo "1" > $dvi/enabled

After this the configuration looks like:::

	FB0 --- GFX  -\         -- DVI
	FB1 --- VID1 --+- LCD -/   LCD
	FB2 --- VID2 -/   TV ----- TV

Example: Clone GFX overlay to LCD and TV
----------------------------------------

::

	w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1`
	h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1`

	echo "0" > $ovl0/enabled
	echo "0" > $ovl1/enabled

	echo "" > $fb1/overlays
	echo "0,1" > $fb0/overlays

	echo "$w,$h" > $ovl1/output_size
	echo "tv" > $ovl1/manager

	echo "1" > $ovl0/enabled
	echo "1" > $ovl1/enabled

	echo "1" > $tv/enabled

After this the configuration looks like (only relevant parts shown)::

	FB0 +-- GFX  ---- LCD ---- LCD
	\- VID1 ---- TV  ---- TV

Misc notes
----------

OMAP FB allocates the framebuffer memory using the standard dma allocator. You
can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma
allocator, and if CMA is enabled, you use "cma=" kernel parameter to increase
the global memory area for CMA.

Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.

Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB
does not support mirroring.

VRFB rotation requires much more memory than non-rotated framebuffer, so you
probably need to increase your vram setting before using VRFB rotation. Also,
many applications may not work with VRFB if they do not pay attention to all
framebuffer parameters.

Kernel boot arguments
---------------------

omapfb.mode=<display>:<mode>[,...]
	- Default video mode for specified displays. For example,
	  "dvi:800x400MR-24@60".  See drivers/video/modedb.c.
	  There are also two special modes: "pal" and "ntsc" that
	  can be used to tv out.

omapfb.vram=<fbnum>:<size>[@<physaddr>][,...]
	- VRAM allocated for a framebuffer. Normally omapfb allocates vram
	  depending on the display size. With this you can manually allocate
	  more or define the physical address of each framebuffer. For example,
	  "1:4M" to allocate 4M for fb1.

omapfb.debug=<y|n>
	- Enable debug printing. You have to have OMAPFB debug support enabled
	  in kernel config.

omapfb.test=<y|n>
	- Draw test pattern to framebuffer whenever framebuffer settings change.
	  You need to have OMAPFB debug support enabled in kernel config.

omapfb.vrfb=<y|n>
	- Use VRFB rotation for all framebuffers.

omapfb.rotate=<angle>
	- Default rotation applied to all framebuffers.
	  0 - 0 degree rotation
	  1 - 90 degree rotation
	  2 - 180 degree rotation
	  3 - 270 degree rotation

omapfb.mirror=<y|n>
	- Default mirror for all framebuffers. Only works with DMA rotation.

omapdss.def_disp=<display>
	- Name of default display, to which all overlays will be connected.
	  Common examples are "lcd" or "tv".

omapdss.debug=<y|n>
	- Enable debug printing. You have to have DSS debug support enabled in
	  kernel config.

TODO
----

DSS locking

Error checking

- Lots of checks are missing or implemented just as BUG()

System DMA update for DSI

- Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how
  to skip the empty byte?)

OMAP1 support

- Not sure if needed


code:
.. SPDX-License-Identifier: GPL-2.0

=======
TI OMAP
=======

.. toctree::
   :maxdepth: 1

   omap
   omap_pm
   dss


code:
============
OMAP history
============

This file contains documentation for running mainline
kernel on omaps.

======		======================================================
KERNEL		NEW DEPENDENCIES
======		======================================================
v4.3+		Update is needed for custom .config files to make sure
		CONFIG_REGULATOR_PBIAS is enabled for MMC1 to work
		properly.

v4.18+		Update is needed for custom .config files to make sure
		CONFIG_MMC_SDHCI_OMAP is enabled for all MMC instances
		to work in DRA7 and K2G based boards.
======		======================================================


code:
=====================
The OMAP PM interface
=====================

This document describes the temporary OMAP PM interface.  Driver
authors use these functions to communicate minimum latency or
throughput constraints to the kernel power management code.
Over time, the intention is to merge features from the OMAP PM
interface into the Linux PM QoS code.

Drivers need to express PM parameters which:

- support the range of power management parameters present in the TI SRF;

- separate the drivers from the underlying PM parameter
  implementation, whether it is the TI SRF or Linux PM QoS or Linux
  latency framework or something else;

- specify PM parameters in terms of fundamental units, such as
  latency and throughput, rather than units which are specific to OMAP
  or to particular OMAP variants;

- allow drivers which are shared with other architectures (e.g.,
  DaVinci) to add these constraints in a way which won't affect non-OMAP
  systems,

- can be implemented immediately with minimal disruption of other
  architectures.

This document proposes the OMAP PM interface, including the following
five power management functions for driver code:

1. Set the maximum MPU wakeup latency::

   (*pdata->set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t)

2. Set the maximum device wakeup latency::

   (*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t)

3. Set the maximum system DMA transfer start latency (CORE pwrdm)::

   (*pdata->set_max_sdma_lat)(struct device *dev, long t)

4. Set the minimum bus throughput needed by a device::

   (*pdata->set_min_bus_tput)(struct device *dev, u8 agent_id, unsigned long r)

5. Return the number of times the device has lost context::

   (*pdata->get_dev_context_loss_count)(struct device *dev)

Further documentation for all OMAP PM interface functions can be
found in arch/arm/plat-omap/include/mach/omap-pm.h.

The OMAP PM layer is intended to be temporary
---------------------------------------------

The intention is that eventually the Linux PM QoS layer should support
the range of power management features present in OMAP3.  As this
happens, existing drivers using the OMAP PM interface can be modified
to use the Linux PM QoS code; and the OMAP PM interface can disappear.

Driver usage of the OMAP PM functions
-------------------------------------

As the 'pdata' in the above examples indicates, these functions are
exposed to drivers through function pointers in driver .platform_data
structures.  The function pointers are initialized by the `board-*.c`
files to point to the corresponding OMAP PM functions:

- set_max_dev_wakeup_lat will point to
  omap_pm_set_max_dev_wakeup_lat(), etc.  Other architectures which do
  not support these functions should leave these function pointers set
  to NULL.  Drivers should use the following idiom::

        if (pdata->set_max_dev_wakeup_lat)
            (*pdata->set_max_dev_wakeup_lat)(dev, t);

The most common usage of these functions will probably be to specify
the maximum time from when an interrupt occurs, to when the device
becomes accessible.  To accomplish this, driver writers should use the
set_max_mpu_wakeup_lat() function to constrain the MPU wakeup
latency, and the set_max_dev_wakeup_lat() function to constrain the
device wakeup latency (from clk_enable() to accessibility).  For
example::

        /* Limit MPU wakeup latency */
        if (pdata->set_max_mpu_wakeup_lat)
            (*pdata->set_max_mpu_wakeup_lat)(dev, tc);

        /* Limit device powerdomain wakeup latency */
        if (pdata->set_max_dev_wakeup_lat)
            (*pdata->set_max_dev_wakeup_lat)(dev, td);

        /* total wakeup latency in this example: (tc + td) */

The PM parameters can be overwritten by calling the function again
with the new value.  The settings can be removed by calling the
function with a t argument of -1 (except in the case of
set_max_bus_tput(), which should be called with an r argument of 0).

The fifth function above, omap_pm_get_dev_context_loss_count(),
is intended as an optimization to allow drivers to determine whether the
device has lost its internal context.  If context has been lost, the
driver must restore its internal context before proceeding.

Other specialized interface functions
-------------------------------------

The five functions listed above are intended to be usable by any
device driver.  DSPBridge and CPUFreq have a few special requirements.
DSPBridge expresses target DSP performance levels in terms of OPP IDs.
CPUFreq expresses target MPU performance levels in terms of MPU
frequency.  The OMAP PM interface contains functions for these
specialized cases to convert that input information (OPPs/MPU
frequency) into the form that the underlying power management
implementation needs:

6. `(*pdata->dsp_get_opp_table)(void)`

7. `(*pdata->dsp_set_min_opp)(u8 opp_id)`

8. `(*pdata->dsp_get_opp)(void)`

9. `(*pdata->cpu_get_freq_table)(void)`

10. `(*pdata->cpu_set_freq)(unsigned long f)`

11. `(*pdata->cpu_get_freq)(void)`

Customizing OPP for platform
============================
Defining CONFIG_PM should enable OPP layer for the silicon
and the registration of OPP table should take place automatically.
However, in special cases, the default OPP table may need to be
tweaked, for e.g.:

 * enable default OPPs which are disabled by default, but which
   could be enabled on a platform
 * Disable an unsupported OPP on the platform
 * Define and add a custom opp table entry
   in these cases, the board file needs to do additional steps as follows:

arch/arm/mach-omapx/board-xyz.c::

	#include "pm.h"
	....
	static void __init omap_xyz_init_irq(void)
	{
		....
		/* Initialize the default table */
		omapx_opp_init();
		/* Do customization to the defaults */
		....
	}

NOTE:
  omapx_opp_init will be omap3_opp_init or as required
  based on the omap family.


code:
=======
Porting
=======

Taken from list archive at http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.html

Initial definitions
-------------------

The following symbol definitions rely on you knowing the translation that
__virt_to_phys() does for your machine.  This macro converts the passed
virtual address to a physical address.  Normally, it is simply:

		phys = virt - PAGE_OFFSET + PHYS_OFFSET

Decompressor Symbols
--------------------

ZTEXTADDR
	Start address of decompressor.  There's no point in talking about
	virtual or physical addresses here, since the MMU will be off at
	the time when you call the decompressor code.  You normally call
	the kernel at this address to start it booting.  This doesn't have
	to be located in RAM, it can be in flash or other read-only or
	read-write addressable medium.

ZBSSADDR
	Start address of zero-initialised work area for the decompressor.
	This must be pointing at RAM.  The decompressor will zero initialise
	this for you.  Again, the MMU will be off.

ZRELADDR
	This is the address where the decompressed kernel will be written,
	and eventually executed.  The following constraint must be valid:

		__virt_to_phys(TEXTADDR) == ZRELADDR

	The initial part of the kernel is carefully coded to be position
	independent.

INITRD_PHYS
	Physical address to place the initial RAM disk.  Only relevant if
	you are using the bootpImage stuff (which only works on the old
	struct param_struct).

INITRD_VIRT
	Virtual address of the initial RAM disk.  The following  constraint
	must be valid:

		__virt_to_phys(INITRD_VIRT) == INITRD_PHYS

PARAMS_PHYS
	Physical address of the struct param_struct or tag list, giving the
	kernel various parameters about its execution environment.

Kernel Symbols
--------------

PHYS_OFFSET
	Physical start address of the first bank of RAM.

PAGE_OFFSET
	Virtual start address of the first bank of RAM.  During the kernel
	boot phase, virtual address PAGE_OFFSET will be mapped to physical
	address PHYS_OFFSET, along with any other mappings you supply.
	This should be the same value as TASK_SIZE.

TASK_SIZE
	The maximum size of a user process in bytes.  Since user space
	always starts at zero, this is the maximum address that a user
	process can access+1.  The user space stack grows down from this
	address.

	Any virtual address below TASK_SIZE is deemed to be user process
	area, and therefore managed dynamically on a process by process
	basis by the kernel.  I'll call this the user segment.

	Anything above TASK_SIZE is common to all processes.  I'll call
	this the kernel segment.

	(In other words, you can't put IO mappings below TASK_SIZE, and
	hence PAGE_OFFSET).

TEXTADDR
	Virtual start address of kernel, normally PAGE_OFFSET + 0x8000.
	This is where the kernel image ends up.  With the latest kernels,
	it must be located at 32768 bytes into a 128MB region.  Previous
	kernels placed a restriction of 256MB here.

DATAADDR
	Virtual address for the kernel data segment.  Must not be defined
	when using the decompressor.

VMALLOC_START / VMALLOC_END
	Virtual addresses bounding the vmalloc() area.  There must not be
	any static mappings in this area; vmalloc will overwrite them.
	The addresses must also be in the kernel segment (see above).
	Normally, the vmalloc() area starts VMALLOC_OFFSET bytes above the
	last virtual RAM address (found using variable high_memory).

VMALLOC_OFFSET
	Offset normally incorporated into VMALLOC_START to provide a hole
	between virtual RAM and the vmalloc area.  We do this to allow
	out of bounds memory accesses (eg, something writing off the end
	of the mapped memory map) to be caught.  Normally set to 8MB.

Architecture Specific Macros
----------------------------

BOOT_MEM(pram,pio,vio)
	`pram` specifies the physical start address of RAM.  Must always
	be present, and should be the same as PHYS_OFFSET.

	`pio` is the physical address of an 8MB region containing IO for
	use with the debugging macros in arch/arm/kernel/debug-armv.S.

	`vio` is the virtual address of the 8MB debugging region.

	It is expected that the debugging region will be re-initialised
	by the architecture specific code later in the code (via the
	MAPIO function).

BOOT_PARAMS
	Same as, and see PARAMS_PHYS.

FIXUP(func)
	Machine specific fixups, run before memory subsystems have been
	initialised.

MAPIO(func)
	Machine specific function to map IO areas (including the debug
	region above).

INITIRQ(func)
	Machine specific function to initialise interrupts.


code:
==============================================
MFP Configuration for PXA2xx/PXA3xx Processors
==============================================

			Eric Miao <eric.miao@marvell.com>

MFP stands for Multi-Function Pin, which is the pin-mux logic on PXA3xx and
later PXA series processors.  This document describes the existing MFP API,
and how board/platform driver authors could make use of it.

Basic Concept
=============

Unlike the GPIO alternate function settings on PXA25x and PXA27x, a new MFP
mechanism is introduced from PXA3xx to completely move the pin-mux functions
out of the GPIO controller. In addition to pin-mux configurations, the MFP
also controls the low power state, driving strength, pull-up/down and event
detection of each pin.  Below is a diagram of internal connections between
the MFP logic and the remaining SoC peripherals::

 +--------+
 |        |--(GPIO19)--+
 |  GPIO  |            |
 |        |--(GPIO...) |
 +--------+            |
                       |       +---------+
 +--------+            +------>|         |
 |  PWM2  |--(PWM_OUT)-------->|   MFP   |
 +--------+            +------>|         |-------> to external PAD
                       | +---->|         |
 +--------+            | | +-->|         |
 |  SSP2  |---(TXD)----+ | |   +---------+
 +--------+              | |
                         | |
 +--------+              | |
 | Keypad |--(MKOUT4)----+ |
 +--------+                |
                           |
 +--------+                |
 |  UART2 |---(TXD)--------+
 +--------+

NOTE: the external pad is named as MFP_PIN_GPIO19, it doesn't necessarily
mean it's dedicated for GPIO19, only as a hint that internally this pin
can be routed from GPIO19 of the GPIO controller.

To better understand the change from PXA25x/PXA27x GPIO alternate function
to this new MFP mechanism, here are several key points:

  1. GPIO controller on PXA3xx is now a dedicated controller, same as other
     internal controllers like PWM, SSP and UART, with 128 internal signals
     which can be routed to external through one or more MFPs (e.g. GPIO<0>
     can be routed through either MFP_PIN_GPIO0 as well as MFP_PIN_GPIO0_2,
     see arch/arm/mach-pxa/mfp-pxa300.h)

  2. Alternate function configuration is removed from this GPIO controller,
     the remaining functions are pure GPIO-specific, i.e.

       - GPIO signal level control
       - GPIO direction control
       - GPIO level change detection

  3. Low power state for each pin is now controlled by MFP, this means the
     PGSRx registers on PXA2xx are now useless on PXA3xx

  4. Wakeup detection is now controlled by MFP, PWER does not control the
     wakeup from GPIO(s) any more, depending on the sleeping state, ADxER
     (as defined in pxa3xx-regs.h) controls the wakeup from MFP

NOTE: with such a clear separation of MFP and GPIO, by GPIO<xx> we normally
mean it is a GPIO signal, and by MFP<xxx> or pin xxx, we mean a physical
pad (or ball).

MFP API Usage
=============

For board code writers, here are some guidelines:

1. include ONE of the following header files in your <board>.c:

   - #include "mfp-pxa25x.h"
   - #include "mfp-pxa27x.h"
   - #include "mfp-pxa300.h"
   - #include "mfp-pxa320.h"
   - #include "mfp-pxa930.h"

   NOTE: only one file in your <board>.c, depending on the processors used,
   because pin configuration definitions may conflict in these file (i.e.
   same name, different meaning and settings on different processors). E.g.
   for zylonite platform, which support both PXA300/PXA310 and PXA320, two
   separate files are introduced: zylonite_pxa300.c and zylonite_pxa320.c
   (in addition to handle MFP configuration differences, they also handle
   the other differences between the two combinations).

   NOTE: PXA300 and PXA310 are almost identical in pin configurations (with
   PXA310 supporting some additional ones), thus the difference is actually
   covered in a single mfp-pxa300.h.

2. prepare an array for the initial pin configurations, e.g.::

     static unsigned long mainstone_pin_config[] __initdata = {
	/* Chip Select */
	GPIO15_nCS_1,

	/* LCD - 16bpp Active TFT */
	GPIOxx_TFT_LCD_16BPP,
	GPIO16_PWM0_OUT,	/* Backlight */

	/* MMC */
	GPIO32_MMC_CLK,
	GPIO112_MMC_CMD,
	GPIO92_MMC_DAT_0,
	GPIO109_MMC_DAT_1,
	GPIO110_MMC_DAT_2,
	GPIO111_MMC_DAT_3,

	...

	/* GPIO */
	GPIO1_GPIO | WAKEUP_ON_EDGE_BOTH,
     };

   a) once the pin configurations are passed to pxa{2xx,3xx}_mfp_config(),
   and written to the actual registers, they are useless and may discard,
   adding '__initdata' will help save some additional bytes here.

   b) when there is only one possible pin configurations for a component,
   some simplified definitions can be used, e.g. GPIOxx_TFT_LCD_16BPP on
   PXA25x and PXA27x processors

   c) if by board design, a pin can be configured to wake up the system
   from low power state, it can be 'OR'ed with any of:

      WAKEUP_ON_EDGE_BOTH
      WAKEUP_ON_EDGE_RISE
      WAKEUP_ON_EDGE_FALL
      WAKEUP_ON_LEVEL_HIGH - specifically for enabling of keypad GPIOs,

   to indicate that this pin has the capability of wake-up the system,
   and on which edge(s). This, however, doesn't necessarily mean the
   pin _will_ wakeup the system, it will only when set_irq_wake() is
   invoked with the corresponding GPIO IRQ (GPIO_IRQ(xx) or gpio_to_irq())
   and eventually calls gpio_set_wake() for the actual register setting.

   d) although PXA3xx MFP supports edge detection on each pin, the
   internal logic will only wakeup the system when those specific bits
   in ADxER registers are set, which can be well mapped to the
   corresponding peripheral, thus set_irq_wake() can be called with
   the peripheral IRQ to enable the wakeup.

MFP on PXA3xx
=============

Every external I/O pad on PXA3xx (excluding those for special purpose) has
one MFP logic associated, and is controlled by one MFP register (MFPR).

The MFPR has the following bit definitions (for PXA300/PXA310/PXA320)::

 31                        16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
  +-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |         RESERVED        |PS|PU|PD|  DRIVE |SS|SD|SO|EC|EF|ER|--| AF_SEL |
  +-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

  Bit 3:   RESERVED
  Bit 4:   EDGE_RISE_EN - enable detection of rising edge on this pin
  Bit 5:   EDGE_FALL_EN - enable detection of falling edge on this pin
  Bit 6:   EDGE_CLEAR   - disable edge detection on this pin
  Bit 7:   SLEEP_OE_N   - enable outputs during low power modes
  Bit 8:   SLEEP_DATA   - output data on the pin during low power modes
  Bit 9:   SLEEP_SEL    - selection control for low power modes signals
  Bit 13:  PULLDOWN_EN  - enable the internal pull-down resistor on this pin
  Bit 14:  PULLUP_EN    - enable the internal pull-up resistor on this pin
  Bit 15:  PULL_SEL     - pull state controlled by selected alternate function
                          (0) or by PULL{UP,DOWN}_EN bits (1)

  Bit 0 - 2: AF_SEL - alternate function selection, 8 possibilities, from 0-7
  Bit 10-12: DRIVE  - drive strength and slew rate
			0b000 - fast 1mA
			0b001 - fast 2mA
			0b002 - fast 3mA
			0b003 - fast 4mA
			0b004 - slow 6mA
			0b005 - fast 6mA
			0b006 - slow 10mA
			0b007 - fast 10mA

MFP Design for PXA2xx/PXA3xx
============================

Due to the difference of pin-mux handling between PXA2xx and PXA3xx, a unified
MFP API is introduced to cover both series of processors.

The basic idea of this design is to introduce definitions for all possible pin
configurations, these definitions are processor and platform independent, and
the actual API invoked to convert these definitions into register settings and
make them effective there-after.

Files Involved
--------------

  - arch/arm/mach-pxa/include/mach/mfp.h

  for
    1. Unified pin definitions - enum constants for all configurable pins
    2. processor-neutral bit definitions for a possible MFP configuration

  - arch/arm/mach-pxa/mfp-pxa3xx.h

  for PXA3xx specific MFPR register bit definitions and PXA3xx common pin
  configurations

  - arch/arm/mach-pxa/mfp-pxa2xx.h

  for PXA2xx specific definitions and PXA25x/PXA27x common pin configurations

  - arch/arm/mach-pxa/mfp-pxa25x.h
    arch/arm/mach-pxa/mfp-pxa27x.h
    arch/arm/mach-pxa/mfp-pxa300.h
    arch/arm/mach-pxa/mfp-pxa320.h
    arch/arm/mach-pxa/mfp-pxa930.h

  for processor specific definitions

  - arch/arm/mach-pxa/mfp-pxa3xx.c
  - arch/arm/mach-pxa/mfp-pxa2xx.c

  for implementation of the pin configuration to take effect for the actual
  processor.

Pin Configuration
-----------------

  The following comments are copied from mfp.h (see the actual source code
  for most updated info)::

    /*
     * a possible MFP configuration is represented by a 32-bit integer
     *
     * bit  0.. 9 - MFP Pin Number (1024 Pins Maximum)
     * bit 10..12 - Alternate Function Selection
     * bit 13..15 - Drive Strength
     * bit 16..18 - Low Power Mode State
     * bit 19..20 - Low Power Mode Edge Detection
     * bit 21..22 - Run Mode Pull State
     *
     * to facilitate the definition, the following macros are provided
     *
     * MFP_CFG_DEFAULT - default MFP configuration value, with
     * 		  alternate function = 0,
     * 		  drive strength = fast 3mA (MFP_DS03X)
     * 		  low power mode = default
     * 		  edge detection = none
     *
     * MFP_CFG	- default MFPR value with alternate function
     * MFP_CFG_DRV	- default MFPR value with alternate function and
     * 		  pin drive strength
     * MFP_CFG_LPM	- default MFPR value with alternate function and
     * 		  low power mode
     * MFP_CFG_X	- default MFPR value with alternate function,
     * 		  pin drive strength and low power mode
     */

   Examples of pin configurations are::

     #define GPIO94_SSP3_RXD		MFP_CFG_X(GPIO94, AF1, DS08X, FLOAT)

   which reads GPIO94 can be configured as SSP3_RXD, with alternate function
   selection of 1, driving strength of 0b101, and a float state in low power
   modes.

   NOTE: this is the default setting of this pin being configured as SSP3_RXD
   which can be modified a bit in board code, though it is not recommended to
   do so, simply because this default setting is usually carefully encoded,
   and is supposed to work in most cases.

Register Settings
-----------------

   Register settings on PXA3xx for a pin configuration is actually very
   straight-forward, most bits can be converted directly into MFPR value
   in a easier way. Two sets of MFPR values are calculated: the run-time
   ones and the low power mode ones, to allow different settings.

   The conversion from a generic pin configuration to the actual register
   settings on PXA2xx is a bit complicated: many registers are involved,
   including GAFRx, GPDRx, PGSRx, PWER, PKWR, PFER and PRER. Please see
   mfp-pxa2xx.c for how the conversion is made.


code:
============================================
The Intel Assabet (SA-1110 evaluation) board
============================================

Please see:
http://developer.intel.com

Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>:
http://www.cs.cmu.edu/~wearable/software/assabet.html

Building the kernel
-------------------

To build the kernel with current defaults::

	make assabet_defconfig
	make oldconfig
	make zImage

The resulting kernel image should be available in linux/arch/arm/boot/zImage.

Installing a bootloader
-----------------------

A couple of bootloaders able to boot Linux on Assabet are available:

BLOB (http://www.lartmaker.nl/lartware/blob/)

   BLOB is a bootloader used within the LART project.  Some contributed
   patches were merged into BLOB to add support for Assabet.

Compaq's Bootldr + John Dorsey's patch for Assabet support
(http://www.handhelds.org/Compaq/bootldr.html)
(http://www.wearablegroup.org/software/bootldr/)

   Bootldr is the bootloader developed by Compaq for the iPAQ Pocket PC.
   John Dorsey has produced add-on patches to add support for Assabet and
   the JFFS filesystem.

RedBoot (http://sources.redhat.com/redboot/)

   RedBoot is a bootloader developed by Red Hat based on the eCos RTOS
   hardware abstraction layer.  It supports Assabet amongst many other
   hardware platforms.

RedBoot is currently the recommended choice since it's the only one to have
networking support, and is the most actively maintained.

Brief examples on how to boot Linux with RedBoot are shown below.  But first
you need to have RedBoot installed in your flash memory.  A known to work
precompiled RedBoot binary is available from the following location:

- ftp://ftp.netwinder.org/users/n/nico/
- ftp://ftp.arm.linux.org.uk/pub/linux/arm/people/nico/
- ftp://ftp.handhelds.org/pub/linux/arm/sa-1100-patches/

Look for redboot-assabet*.tgz.  Some installation infos are provided in
redboot-assabet*.txt.

Initial RedBoot configuration
-----------------------------

The commands used here are explained in The RedBoot User's Guide available
on-line at http://sources.redhat.com/ecos/docs.html.
Please refer to it for explanations.

If you have a CF network card (my Assabet kit contained a CF+ LP-E from
Socket Communications Inc.), you should strongly consider using it for TFTP
file transfers.  You must insert it before RedBoot runs since it can't detect
it dynamically.

To initialize the flash directory::

	fis init -f

To initialize the non-volatile settings, like whether you want to use BOOTP or
a static IP address, etc, use this command::

	fconfig -i

Writing a kernel image into flash
---------------------------------

First, the kernel image must be loaded into RAM.  If you have the zImage file
available on a TFTP server::

	load zImage -r -b 0x100000

If you rather want to use Y-Modem upload over the serial port::

	load -m ymodem -r -b 0x100000

To write it to flash::

	fis create "Linux kernel" -b 0x100000 -l 0xc0000

Booting the kernel
------------------

The kernel still requires a filesystem to boot.  A ramdisk image can be loaded
as follows::

	load ramdisk_image.gz -r -b 0x800000

Again, Y-Modem upload can be used instead of TFTP by replacing the file name
by '-y ymodem'.

Now the kernel can be retrieved from flash like this::

	fis load "Linux kernel"

or loaded as described previously.  To boot the kernel::

	exec -b 0x100000 -l 0xc0000

The ramdisk image could be stored into flash as well, but there are better
solutions for on-flash filesystems as mentioned below.

Using JFFS2
-----------

Using JFFS2 (the Second Journalling Flash File System) is probably the most
convenient way to store a writable filesystem into flash.  JFFS2 is used in
conjunction with the MTD layer which is responsible for low-level flash
management.  More information on the Linux MTD can be found on-line at:
http://www.linux-mtd.infradead.org/.  A JFFS howto with some infos about
creating JFFS/JFFS2 images is available from the same site.

For instance, a sample JFFS2 image can be retrieved from the same FTP sites
mentioned below for the precompiled RedBoot image.

To load this file::

	load sample_img.jffs2 -r -b 0x100000

The result should look like::

	RedBoot> load sample_img.jffs2 -r -b 0x100000
	Raw file loaded 0x00100000-0x00377424

Now we must know the size of the unallocated flash::

	fis free

Result::

	RedBoot> fis free
	  0x500E0000 .. 0x503C0000

The values above may be different depending on the size of the filesystem and
the type of flash.  See their usage below as an example and take care of
substituting yours appropriately.

We must determine some values::

	size of unallocated flash:	0x503c0000 - 0x500e0000 = 0x2e0000
	size of the filesystem image:	0x00377424 - 0x00100000 = 0x277424

We want to fit the filesystem image of course, but we also want to give it all
the remaining flash space as well.  To write it::

	fis unlock -f 0x500E0000 -l 0x2e0000
	fis erase -f 0x500E0000 -l 0x2e0000
	fis write -b 0x100000 -l 0x277424 -f 0x500E0000
	fis create "JFFS2" -n -f 0x500E0000 -l 0x2e0000

Now the filesystem is associated to a MTD "partition" once Linux has discovered
what they are in the boot process.  From Redboot, the 'fis list' command
displays them::

	RedBoot> fis list
	Name              FLASH addr  Mem addr    Length      Entry point
	RedBoot           0x50000000  0x50000000  0x00020000  0x00000000
	RedBoot config    0x503C0000  0x503C0000  0x00020000  0x00000000
	FIS directory     0x503E0000  0x503E0000  0x00020000  0x00000000
	Linux kernel      0x50020000  0x00100000  0x000C0000  0x00000000
	JFFS2             0x500E0000  0x500E0000  0x002E0000  0x00000000

However Linux should display something like::

	SA1100 flash: probing 32-bit flash bus
	SA1100 flash: Found 2 x16 devices at 0x0 in 32-bit mode
	Using RedBoot partition definition
	Creating 5 MTD partitions on "SA1100 flash":
	0x00000000-0x00020000 : "RedBoot"
	0x00020000-0x000e0000 : "Linux kernel"
	0x000e0000-0x003c0000 : "JFFS2"
	0x003c0000-0x003e0000 : "RedBoot config"
	0x003e0000-0x00400000 : "FIS directory"

What's important here is the position of the partition we are interested in,
which is the third one.  Within Linux, this correspond to /dev/mtdblock2.
Therefore to boot Linux with the kernel and its root filesystem in flash, we
need this RedBoot command::

	fis load "Linux kernel"
	exec -b 0x100000 -l 0xc0000 -c "root=/dev/mtdblock2"

Of course other filesystems than JFFS might be used, like cramfs for example.
You might want to boot with a root filesystem over NFS, etc.  It is also
possible, and sometimes more convenient, to flash a filesystem directly from
within Linux while booted from a ramdisk or NFS.  The Linux MTD repository has
many tools to deal with flash memory as well, to erase it for example.  JFFS2
can then be mounted directly on a freshly erased partition and files can be
copied over directly.  Etc...

RedBoot scripting
-----------------

All the commands above aren't so useful if they have to be typed in every
time the Assabet is rebooted.  Therefore it's possible to automate the boot
process using RedBoot's scripting capability.

For example, I use this to boot Linux with both the kernel and the ramdisk
images retrieved from a TFTP server on the network::

	RedBoot> fconfig
	Run script at boot: false true
	Boot script:
	Enter script, terminate with empty line
	>> load zImage -r -b 0x100000
	>> load ramdisk_ks.gz -r -b 0x800000
	>> exec -b 0x100000 -l 0xc0000
	>>
	Boot script timeout (1000ms resolution): 3
	Use BOOTP for network configuration: true
	GDB connection port: 9000
	Network debug at boot time: false
	Update RedBoot non-volatile configuration - are you sure (y/n)? y

Then, rebooting the Assabet is just a matter of waiting for the login prompt.

Nicolas Pitre
nico@fluxnic.net

June 12, 2001

Status of peripherals in -rmk tree (updated 14/10/2001)
-------------------------------------------------------

Assabet:
 Serial ports:
  Radio:		TX, RX, CTS, DSR, DCD, RI
   - PM:		Not tested.
   - COM:		TX, RX, CTS, DSR, DCD, RTS, DTR, PM
   - PM:		Not tested.
   - I2C:		Implemented, not fully tested.
   - L3:		Fully tested, pass.
   - PM:		Not tested.

 Video:
  - LCD:		Fully tested.  PM

   (LCD doesn't like being blanked with neponset connected)

  - Video out:		Not fully

 Audio:
  UDA1341:
  -  Playback:		Fully tested, pass.
  -  Record:		Implemented, not tested.
  -  PM:			Not tested.

  UCB1200:
  -  Audio play:	Implemented, not heavily tested.
  -  Audio rec:		Implemented, not heavily tested.
  -  Telco audio play:	Implemented, not heavily tested.
  -  Telco audio rec:	Implemented, not heavily tested.
  -  POTS control:	No
  -  Touchscreen:	Yes
  -  PM:		Not tested.

 Other:
  - PCMCIA:
  - LPE:		Fully tested, pass.
  - USB:		No
  - IRDA:
  - SIR:		Fully tested, pass.
  - FIR:		Fully tested, pass.
  - PM:			Not tested.

Neponset:
 Serial ports:
  - COM1,2:		TX, RX, CTS, DSR, DCD, RTS, DTR
  - PM:			Not tested.
  - USB:		Implemented, not heavily tested.
  - PCMCIA:		Implemented, not heavily tested.
  - CF:			Implemented, not heavily tested.
  - PM:			Not tested.

More stuff can be found in the -np (Nicolas Pitre's) tree.


code:
==============
CerfBoard/Cube
==============

*** The StrongARM version of the CerfBoard/Cube has been discontinued ***

The Intrinsyc CerfBoard is a StrongARM 1110-based computer on a board
that measures approximately 2" square. It includes an Ethernet
controller, an RS232-compatible serial port, a USB function port, and
one CompactFlash+ slot on the back. Pictures can be found at the
Intrinsyc website, http://www.intrinsyc.com.

This document describes the support in the Linux kernel for the
Intrinsyc CerfBoard.

Supported in this version
=========================

   - CompactFlash+ slot (select PCMCIA in General Setup and any options
     that may be required)
   - Onboard Crystal CS8900 Ethernet controller (Cerf CS8900A support in
     Network Devices)
   - Serial ports with a serial console (hardcoded to 38400 8N1)

In order to get this kernel onto your Cerf, you need a server that runs
both BOOTP and TFTP. Detailed instructions should have come with your
evaluation kit on how to use the bootloader. This series of commands
will suffice::

   make ARCH=arm CROSS_COMPILE=arm-linux- cerfcube_defconfig
   make ARCH=arm CROSS_COMPILE=arm-linux- zImage
   make ARCH=arm CROSS_COMPILE=arm-linux- modules
   cp arch/arm/boot/zImage <TFTP directory>

support@intrinsyc.com