Core instruction prefetch disable
---------------------------------
To disable instruction prefetch of core; hwconfig needs to be updated.
for e.g.
setenv hwconfig 'fsl_ddr:bank_intlv=auto;core_prefetch:disable=0x02'

Here 0x02 can be replaced with any valid value except Mask[0] bit. It
represents 64 bit mask. The 64-bit Mask has one bit for each core.
Mask[0] = core0
Mask[1] = core1
Mask[2] = core2
etc
If the bit is set ('b1) in the mask, then prefetch is disabled for
that core when it is released from reset.

core0 prefetch should not be disabled i.e. Mask[0] should never be set.
Setting Mask[0] may lead to undefined behavior.

Once disabled, prefetch remains disabled until the next reset.
There is no function to re-enable prefetch.

Falcon boot option
------------------
Falcon boot is a short cut boot method for SD/eMMC targets. It skips loading the
RAM version U-Boot. Instead, it loads FIT image and boot directly to Linux.
CONFIG_SPL_OS_BOOT enables falcon boot. CONFIG_SPL_LOAD_FIT enables the FIT
image support (also need CONFIG_SPL_OF_LIBFDT, CONFIG_SPL_FIT and optionally
CONFIG_SPL_GZIP).

To enable falcon boot, a hook function spl_start_uboot() returns 0 to indicate
booting U-Boot is not the first choice. The kernel FIT image needs to be put
at CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR. SPL mmc driver reads the header to
determine if this is a FIT image. If true, FIT image components are parsed and
copied or decompressed (if applicable) to their destinations. If FIT image is
not found, normal U-Boot flow will follow.

An important part of falcon boot is to prepare the device tree. A normal U-Boot
does FDT fixups when booting Linux. For falcon boot, Linux boots directly from
SPL, skipping the normal U-Boot. The device tree has to be prepared in advance.
A command "spl export" should be called under the normal RAM version U-Boot.
It is equivalent to go through "bootm" step-by-step until device tree fixup is
done. The device tree in memory is the one needed for falcon boot. Falcon boot
flow suggests to save this image to SD/eMMC at the location pointed by macro
CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR, with maximum size specified by macro
CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS. However, when FIT image is used for
Linux, the device tree stored in FIT image overwrites the memory loaded by spl
driver from these sectors. We could change this loading order to favor the
stored sectors. But when secure boot is enabled, these sectors are used for
signature header and needs to be loaded before the FIT image. So it is important
to understand the device tree in FIT image should be the one actually used, or
leave it absent to favor the stored sectors. It is easier to deploy the FIT
image with embedded static device tree to multiple boards.

Macro CONFIG_SYS_SPL_ARGS_ADDR serves two purposes. One is the pointer to load
the stored sectors to. Normally this is the static device tree. The second
purpose is the memory location of signature header for secure boot. After the
FIT image is loaded into memory, it is validated against the signature header
before individual components are extracted (and optionally decompressed) into
their final memory locations, respectively. After the validation, the header
is no longer used. The static device tree is copied into this location. So
this macro is passed as the location of device tree when booting Linux.

Steps to prepare static device tree
-----------------------------------
To prepare the static device tree for Layerscape boards, it is important to
understand the fixups in U-Boot. Memory size and location, as well as reserved
memory blocks are added/updated. Ethernet MAC addressed are updated. FMan
microcode (if used) is embedded in the device tree. Kernel command line and
initrd information are embedded. Others including CPU status, boot method,
Ethernet port status, etc. are also updated.

Following normal booting process, all variables are set, all images are loaded
before "bootm" command would be issued to boot, run command

spl export fdt <address>

where the address is the location of FIT image. U-Boot goes through the booting
process as if "bootm start", "bootm loados", "bootm ramdisk"... commands but
stops before "bootm go". There we have the fixed-up device tree in memory.
We can check the device tree header by these commands

fdt addr <fdt address>
fdt header

Where the fdt address is the device tree in memory. It is printed by U-Boot.
It is useful to know the exact size. One way to extract this static device
tree is to save it to eMMC/SD using command in U-Boot, and extract under Linux
with these commands, repectively

mmc write <address> <sector> <sectors>
dd if=/dev/mmcblk0 of=<filename> bs=512 skip=<sector> count=<sectors>

Note, U-Boot takes values as hexadecimals while Linux takes them as decimals by
default. If using NAND or other storage, the commands are slightly different.
When we have the static device tree image, we can re-make the FIT image with
it. It is important to specify the load addresses in FIT image for every
components. Otherwise U-Boot cannot load them correctly.

Generate FIT image with static device tree
------------------------------------------
Example:

/dts-v1/;

/ {
	description = "Image file for the LS1043A Linux Kernel";
	#address-cells = <1>;

	images {
		kernel {
			description = "ARM64 Linux kernel";
			data = /incbin/("./arch/arm64/boot/Image.gz");
			type = "kernel";
			arch = "arm64";
			os = "linux";
			compression = "gzip";
			load = <0x80080000>;
			entry = <0x80080000>;
		};
		fdt-1 {
			description = "Flattened Device Tree blob";
			data = /incbin/("./fsl-ls1043ardb-static.dtb");
			type = "flat_dt";
			arch = "arm64";
			compression = "none";
			load = <0x90000000>;
		};
		ramdisk {
			description = "LS1043 Ramdisk";
                        data = /incbin/("./rootfs.cpio.gz");
			type = "ramdisk";
			arch = "arm64";
			os = "linux";
			compression = "none";
			load = <0xa0000000>;
		};
	};

	configurations {
		default = "config-1";
		config-1 {
			description = "Boot Linux kernel";
			kernel = "kernel";
			fdt = "fdt-1";
			ramdisk = "ramdisk";
			loadables = "fdt", "ramdisk";
		};
	};
};

The "loadables" is not optional. It tells SPL which images to load into memory.

Falcon mode with QSPI boot
--------------------------
To use falcon mode with QSPI boot, SPL needs to be enabled. Similar to SD or
NAND boot, a RAM version full feature U-Boot is needed. Unlike SD or NAND boot,
SPL with QSPI doesn't need to combine SPL image with RAM version image. Two
separated images are used, u-boot-spl.pbl and u-boot.img. The former is SPL
image with RCW and PBI commands to load the SPL payload into On-Chip RAM. The
latter is RAM version U-Boot in FIT format (or legacy format if FIT is not
used).

Other things to consider
-----------------------
Falcon boot skips a lot of initialization in U-Boot. If Linux expects the
hardware to be initialized by U-Boot, the related code should be ported to SPL
build. For example, if Linux expect Ethernet PHY to be initialized in U-Boot
(which is not a common case), the PHY initialization has to be included in
falcon boot. This increases the SPL image size and should be handled carefully.
If Linux has PHY driver enabled, it still depends on the correct MDIO bus setup
in U-Boot. Normal U-Boot sets the MDC ratio to generate a proper clock signal.

#
# Copyright 2015 Freescale Semiconductor
#
# SPDX-License-Identifier:      GPL-2.0+
#

Freescale LayerScape with Chassis Generation 2

This architecture supports Freescale ARMv8 SoCs with Chassis generation 2,
for example LS1043A.

Watchdog support Overview
-------------------
Support watchdog driver for LSCH2. The driver is disabled in default.
You can enable it by setting CONFIG_IMX_WATCHDOG.
Use following config to set watchdog timeout, if this config is not defined,
the default timeout value is 128s which is the maximum. Set 10 seconds for
example:
Set CONFIG_WATCHDOG_RESET_DISABLE to disable reset watchdog, so that the
watchdog will not be fed in u-boot.

#
# Copyright 2014-2015 Freescale Semiconductor
#
# SPDX-License-Identifier:      GPL-2.0+
#

Freescale LayerScape with Chassis Generation 3

This architecture supports Freescale ARMv8 SoCs with Chassis generation 3,
for example LS2080A.

DDR Layout
============
Entire DDR region splits into two regions.
 - Region 1 is at address 0x8000_0000 to 0xffff_ffff.
 - Region 2 is at 0x80_8000_0000 to the top of total memory,
   for example 16GB, 0x83_ffff_ffff.

All DDR memory is marked as cache-enabled.

When MC and Debug server is enabled, they carve 512MB away from the high
end of DDR. For example, if the total DDR is 16GB, it shrinks to 15.5GB
with MC and Debug server enabled. Linux only sees 15.5GB.

The reserved 512MB layout looks like

   +---------------+ <-- top/end of memory
   |    256MB      |  debug server
   +---------------+
   |    256MB      |  MC
   +---------------+
   |     ...       |

MC requires the memory to be aligned with 512MB, so even debug server is
not enabled, 512MB is reserved, not 256MB.

Flash Layout
============

(1) A typical layout of various images (including Linux and other firmware images)
   is shown below considering a 32MB NOR flash device present on most
   pre-silicon platforms (simulator and emulator):

	-------------------------
	| 	FIT Image	|
	| (linux + DTB + RFS)	|
	------------------------- ----> 0x0120_0000
	| 	Debug Server FW |
	------------------------- ----> 0x00C0_0000
	|	AIOP FW 	|
	------------------------- ----> 0x0070_0000
	|	MC FW 		|
	------------------------- ----> 0x006C_0000
	| 	MC DPL Blob 	|
	------------------------- ----> 0x0020_0000
	| 	BootLoader + Env|
	------------------------- ----> 0x0000_1000
	|	PBI 		|
	------------------------- ----> 0x0000_0080
	|	RCW 		|
	------------------------- ----> 0x0000_0000

	32-MB NOR flash layout for pre-silicon platforms (simulator and emulator)

(2) A typical layout of various images (including Linux and other firmware images)
    is shown below considering a 128MB NOR flash device present on QDS and RDB
    boards:
	----------------------------------------- ----> 0x5_8800_0000 ---
	|	.. Unused .. (7M)		|			|
	----------------------------------------- ----> 0x5_8790_0000	|
	| FIT Image (linux + DTB + RFS)	(40M)	|			|
	----------------------------------------- ----> 0x5_8510_0000	|
	|	PHY firmware (2M)	 	|			|
	----------------------------------------- ----> 0x5_84F0_0000	| 64K
	|	Debug Server FW (2M)		|			| Alt
	----------------------------------------- ----> 0x5_84D0_0000	| Bank
	|	AIOP FW (4M)			|			|
	----------------------------------------- ----> 0x5_8490_0000 (vbank4)
	|	MC DPC Blob (1M) 		|			|
	----------------------------------------- ----> 0x5_8480_0000	|
	|	MC DPL Blob (1M)		|			|
	----------------------------------------- ----> 0x5_8470_0000	|
	| 	MC FW (4M)			|			|
	----------------------------------------- ----> 0x5_8430_0000	|
	|	BootLoader Environment (1M) 	|			|
	----------------------------------------- ----> 0x5_8420_0000	|
	|	BootLoader (1M)			|			|
	----------------------------------------- ----> 0x5_8410_0000	|
	|	RCW and PBI (1M) 		|			|
	----------------------------------------- ----> 0x5_8400_0000 ---
	|	.. Unused .. (7M)		|			|
	----------------------------------------- ----> 0x5_8390_0000	|
	| FIT Image (linux + DTB + RFS)	(40M)	|			|
	----------------------------------------- ----> 0x5_8110_0000	|
	|	PHY firmware (2M)	 	|			|
	----------------------------------------- ----> 0x5_80F0_0000	| 64K
	|	Debug Server FW (2M)		|			| Bank
	----------------------------------------- ----> 0x5_80D0_0000	|
	|	AIOP FW (4M)			|			|
	----------------------------------------- ----> 0x5_8090_0000 (vbank0)
	|	MC DPC Blob (1M) 		|			|
	----------------------------------------- ----> 0x5_8080_0000	|
	|	MC DPL Blob (1M)		|			|
	----------------------------------------- ----> 0x5_8070_0000	|
	| 	MC FW (4M)			|			|
	----------------------------------------- ----> 0x5_8030_0000	|
	|	BootLoader Environment (1M) 	|			|
	----------------------------------------- ----> 0x5_8020_0000	|
	|	BootLoader (1M)			|			|
	----------------------------------------- ----> 0x5_8010_0000	|
	|	RCW and PBI (1M) 		|			|
	----------------------------------------- ----> 0x5_8000_0000 ---

	128-MB NOR flash layout for QDS and RDB boards

Environment Variables
=====================
mcboottimeout:	MC boot timeout in milliseconds. If this variable is not defined
		the value CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS will be assumed.

mcmemsize:	MC DRAM block size in hex. If this variable is not defined, the value
		CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE will be assumed.

mcinitcmd:	This environment variable is defined to initiate MC and DPL deployment
		from the location where it is stored(NOR, NAND, SD, SATA, USB)during
		u-boot booting.If this variable is not defined then MC_BOOT_ENV_VAR
		will be null and MC will not be booted and DPL will not be applied
		during U-boot booting.However the MC, DPC and DPL can be applied from
		console independently.
		The variable needs to be set from the console once and then on
		rebooting the parameters set in the variable will automatically be
		executed. The commmand is demostrated taking an example of mc boot
		using NOR Flash i.e. MC, DPL, and DPC is stored in the NOR flash:

		cp.b 0xa0000000 0x580300000 $filesize
		cp.b 0x80000000 0x580800000 $filesize
		cp.b 0x90000000 0x580700000 $filesize

		setenv mcinitcmd 'fsl_mc start mc 0x580300000 0x580800000'

		If only linux is to be booted then the mcinitcmd environment should be set as

		setenv mcinitcmd 'fsl_mc start mc 0x580300000 0x580800000;fsl_mc apply DPL 0x580700000'

		Here the addresses 0xa0000000, 0x80000000, 0x80000000 are of DDR to where
		MC binary, DPC binary and DPL binary are stored and 0x580300000, 0x580800000
		and 0x580700000 are addresses in NOR where these are copied. It is to be
		noted that these addresses in 'fsl_mc start mc 0x580300000 0x580800000;fsl_mc apply DPL 0x580700000'
		can be replaced with the addresses of DDR to
		which these will be copied in case of these binaries being stored in other
		devices like SATA, USB, NAND, SD etc.

Booting from NAND
-------------------
Booting from NAND requires two images, RCW and u-boot-with-spl.bin.
The difference between NAND boot RCW image and NOR boot image is the PBI
command sequence. Below is one example for PBI commands for LS2085AQDS which
uses NAND device with 2KB/page, block size 128KB.

1) CCSR 4-byte write to 0x00e00404, data=0x00000000
2) CCSR 4-byte write to 0x00e00400, data=0x1800a000
The above two commands set bootloc register to 0x00000000_1800a000 where
the u-boot code will be running in OCRAM.

3) Block Copy: SRC=0x0107, SRC_ADDR=0x00020000, DEST_ADDR=0x1800a000,
BLOCK_SIZE=0x00014000
This command copies u-boot image from NAND device into OCRAM. The values need
to adjust accordingly.

SRC		should match the cfg_rcw_src, the reset config pins. It depends
		on the NAND device. See reference manual for cfg_rcw_src.
SRC_ADDR	is the offset of u-boot-with-spl.bin image in NAND device. In
		the example above, 128KB. For easy maintenance, we put it at
		the beginning of next block from RCW.
DEST_ADDR	is fixed at 0x1800a000, matching bootloc set above.
BLOCK_SIZE	is the size to be copied by PBI.

RCW image should be written to the beginning of NAND device. Example of using
u-boot command

nand write <rcw image in memory> 0 <size of rcw image>

To form the NAND image, build u-boot with NAND config, for example,
ls2080aqds_nand_defconfig. The image needed is u-boot-with-spl.bin.
The u-boot image should be written to match SRC_ADDR, in above example 0x20000.

nand write <u-boot image in memory> 200000 <size of u-boot image>

With these two images in NAND device, the board can boot from NAND.

Another example for LS2085ARDB boards,

1) CCSR 4-byte write to 0x00e00404, data=0x00000000
2) CCSR 4-byte write to 0x00e00400, data=0x1800a000
3) Block Copy: SRC=0x0119, SRC_ADDR=0x00080000, DEST_ADDR=0x1800a000,
BLOCK_SIZE=0x00014000

nand write <rcw image in memory> 0 <size of rcw image>
nand write <u-boot image in memory> 80000 <size of u-boot image>

Notice the difference from QDS is SRC, SRC_ADDR and the offset of u-boot image
to match board NAND device with 4KB/page, block size 512KB.

Note, LS2088A and LS1088A don't support booting from NAND.

Booting from SD/eMMC
-------------------
Booting from SD/eMMC requires two images, RCW and u-boot-with-spl.bin.
The difference between SD boot RCW image and QSPI-NOR boot image is the
PBI command sequence. Below is one example for PBI commands for RDB
and QDS which uses SD device with block size 512. Block location can be
calculated by dividing offset with block size.

1) Block Copy: SRC=0x0040, SRC_ADDR=0x00100000, DEST_ADDR=0x1800a000,
BLOCK_SIZE=0x00016000

This command copies u-boot image from SD device into OCRAM. The values
need to adjust accordingly for SD/eMMC

SRC		should match the cfg_rcw_src, the reset config pins.
		The value for source(SRC) can be 0x0040 or 0x0041
		depending upon SD or eMMC.
SRC_ADDR	is the offset of u-boot-with-spl.bin image in SD device.
		In the example above, 1MB. This is same as QSPI-NOR.
DEST_ADDR	is configured at 0x1800a000, matching bootloc set above.
BLOCK_SIZE	is the size to be copied by PBI.

2) CCSR 4-byte write to 0x01e00404, data=0x00000000
3) CCSR 4-byte write to 0x01e00400, data=0x1800a000
The above two commands set bootloc register to 0x00000000_1800a000 where
the u-boot code will be running in OCRAM.


RCW image should be written at 8th block of device(SD/eMMC). Example of
using u-boot command

mmc erase 0x8 0x10
mmc write <rcw image in memory> 0x8 <size of rcw in block count typical value=10>

To form the SD-Boot image, build u-boot with SD config, for example,
ls1088ardb_sdcard_qspi_defconfig. The image needed is u-boot-with-spl.bin.
The u-boot image should be written to match SRC_ADDR, in above example
offset 0x100000 in other work it means block location 0x800

mmc erase 0x800 0x1800
mmc write <u-boot image in memory> 0x800 <size of u-boot image in block count>

With these two images in SD/eMMC device, the board can boot from SD/eMMC.

MMU Translation Tables
======================

(1) Early MMU Tables:

     Level 0                   Level 1                   Level 2
------------------        ------------------        ------------------
| 0x00_0000_0000 | -----> | 0x00_0000_0000 | -----> | 0x00_0000_0000 |
------------------        ------------------        ------------------
| 0x80_0000_0000 | --|    | 0x00_4000_0000 |        | 0x00_0020_0000 |
------------------   |    ------------------        ------------------
|    invalid     |   |    | 0x00_8000_0000 |        | 0x00_0040_0000 |
------------------   |    ------------------        ------------------
                     |    | 0x00_c000_0000 |        | 0x00_0060_0000 |
                     |    ------------------        ------------------
                     |    | 0x01_0000_0000 |        | 0x00_0080_0000 |
                     |    ------------------        ------------------
                     |            ...                      ...
                     |    ------------------
                     |    | 0x05_8000_0000 |  --|
                     |    ------------------    |
                     |    | 0x05_c000_0000 |    |
                     |    ------------------    |
                     |            ...           |
                     |    ------------------    |   ------------------
                     |--> | 0x80_0000_0000 |    |-> | 0x00_3000_0000 |
                          ------------------        ------------------
                          | 0x80_4000_0000 |        | 0x00_3020_0000 |
                          ------------------        ------------------
                          | 0x80_8000_0000 |        | 0x00_3040_0000 |
                          ------------------        ------------------
                          | 0x80_c000_0000 |        | 0x00_3060_0000 |
                          ------------------        ------------------
                          | 0x81_0000_0000 |        | 0x00_3080_0000 |
                          ------------------        ------------------
			         ...	                   ...

(2) Final MMU Tables:

     Level 0                   Level 1                   Level 2
------------------        ------------------        ------------------
| 0x00_0000_0000 | -----> | 0x00_0000_0000 | -----> | 0x00_0000_0000 |
------------------        ------------------        ------------------
| 0x80_0000_0000 | --|    | 0x00_4000_0000 |        | 0x00_0020_0000 |
------------------   |    ------------------        ------------------
|    invalid     |   |    | 0x00_8000_0000 |        | 0x00_0040_0000 |
------------------   |    ------------------        ------------------
                     |    | 0x00_c000_0000 |        | 0x00_0060_0000 |
                     |    ------------------        ------------------
                     |    | 0x01_0000_0000 |        | 0x00_0080_0000 |
                     |    ------------------        ------------------
                     |            ...                      ...
                     |    ------------------
                     |    | 0x08_0000_0000 | --|
                     |    ------------------   |
                     |    | 0x08_4000_0000 |   |
                     |    ------------------   |
                     |            ...          |
                     |    ------------------   |    ------------------
                     |--> | 0x80_0000_0000 |   |--> | 0x08_0000_0000 |
                          ------------------        ------------------
                          | 0x80_4000_0000 |        | 0x08_0020_0000 |
                          ------------------        ------------------
                          | 0x80_8000_0000 |        | 0x08_0040_0000 |
                          ------------------        ------------------
                          | 0x80_c000_0000 |        | 0x08_0060_0000 |
                          ------------------        ------------------
                          | 0x81_0000_0000 |        | 0x08_0080_0000 |
                          ------------------        ------------------
			         ...	                   ...


DPAA2 commands to manage Management Complex (MC)
------------------------------------------------
DPAA2 commands has been introduced to manage Management Complex
(MC). These commands are used to start mc, aiop and apply DPL
from u-boot command prompt.

Please note Management complex Firmware(MC), DPL and DPC are no
more deployed during u-boot boot-sequence.

Commands:
a) fsl_mc start mc <FW_addr> <DPC_addr> - Start Management Complex
b) fsl_mc apply DPL <DPL_addr> - Apply DPL file
c) fsl_mc start aiop <FW_addr> - Start AIOP

How to use commands :-
1. Command sequence for u-boot ethernet:
   a) fsl_mc start mc <FW_addr> <DPC_addr> - Start Management Complex
   b) DPMAC net-devices are now available for use

   Example-
	Assumption: MC firmware, DPL and DPC dtb is already programmed
	on NOR flash.

	=> fsl_mc start mc 580300000 580800000
	=> setenv ethact DPMAC1@xgmii
	=> ping $serverip

2. Command sequence for Linux boot:
   a) fsl_mc start mc <FW_addr> <DPC_addr> - Start Management Complex
   b) fsl_mc apply DPL <DPL_addr> - Apply DPL file
   c) No DPMAC net-devices are available for use in u-boot
   d) boot Linux

   Example-
	Assumption: MC firmware, DPL and DPC dtb is already programmed
	on NOR flash.

	=> fsl_mc start mc 580300000 580800000
	=> setenv ethact DPMAC1@xgmii
	=> tftp a0000000 kernel.itb
	=> fsl_mc apply dpl 580700000
	=> bootm a0000000

3. Command sequence for AIOP boot:
   a) fsl_mc start mc <FW_addr> <DPC_addr> - Start Management Complex
   b) fsl_mc start aiop <FW_addr> - Start AIOP
   c) fsl_mc apply DPL <DPL_addr> - Apply DPL file
   d) No DPMAC net-devices are availabe for use in u-boot
  Please note actual AIOP start will happen during DPL parsing of
  Management complex

  Example-
	Assumption: MC firmware, DPL, DPC dtb and AIOP firmware is already
	programmed on NOR flash.

	=> fsl_mc start mc 580300000 580800000
	=> fsl_mc start aiop 0x580900000
	=> setenv ethact DPMAC1@xgmii
	=> fsl_mc apply dpl 580700000

Errata A009635
---------------
If the core runs at higher than x3 speed of the platform, there is
possiblity about sev instruction to getting missed by other cores.
This is because of SoC Run Control block may not able to sample
the EVENTI(Sev) signals.

Workaround: Configure Run Control and EPU to periodically send out EVENTI signals to
wake up A57 cores

Errata workaround uses Env variable "a009635_interval_val". It uses decimal
value.
- Default value of env variable is platform clock (MHz)

- User can modify default value by updating the env variable
  setenv a009635_interval_val 600; saveenv;
  It configure platform clock as 600 MHz

- Env variable as 0 signifies no workaround

#
# Copyright 2018 NXP
#
# SPDX-License-Identifier:      GPL-2.0+
#

NXP LayerScape with Chassis Generation 3.2

This architecture supports NXP ARMv8 SoCs with Chassis generation 3.2
for example LX2160A.

This architecture is enhancement over Chassis Generation 3 with
few differences mentioned below

1)DDR Layout
============
Entire DDR region splits into three regions.
 - Region 1 is at address 0x8000_0000 to 0xffff_ffff.
 - Region 2 is at address 0x20_8000_0000 to 0x3f_ffff_ffff,
 - Region 3 is at address 0x60_0000_0000 to the top of memory,
   for example 140GB, 0x63_7fff_ffff.

All DDR memory is marked as cache-enabled.

2)IFC is removed

3)Number of I2C controllers increased to 8

#
# Copyright 2020 NXP
#
# SPDX-License-Identifier:      GPL-2.0+
#

Specifying extra IOMMU mappings for PCI controllers

This feature can be enabled through the PCI_IOMMU_EXTRA_MAPPINGS Kconfig option.

The "pci_iommu_extra" env var or "pci-iommu-extra" device tree property (to be
used for example in more static scenarios such as hardwired PCI endpoints that
get initialized later in the system setup) allows two things:
 - for a SRIOV capable PCI EP identified by its B.D.F specify the maximum number
   of VFs that will ever be created for it
 - for hot-plug case, specify the B.D.F with which the device will show up on
   the PCI bus

The env var consists of a list of <bdf>,<action> pairs for a certain pci bus
identified by its controller's base register address, as defined in the "reg"
property in the device tree.

pci_iommu_extra = pci@<addr1>,<bdf>,<action>,<bdf>,<action>,
		  pci@<addr2>,<bdf>,<action>,<bdf>,<action>,...

where:
 <addr> is the base register address of the pci controller for which the
        subsequent <bdf>,<action> pairs apply
 <bdf> identifies to which B.D.F the action applies to
 <action> can be:
    - "vfs=<number>" to specify that for the PCI EP identified previously by
      the <bdf> to include mappings for <number> of VFs.
      The variant "noari_vfs=<number>" is available to disable taking ARI into
      account.
    - "hp" to specify that on this <bdf> there will be a hot-plugged device so
      it needs a mapping
The device tree property must be placed under the correct pci controller node
and only the bdf and action pairs need to be specified, like this:

pci-iommu-extra = "<bdf>,<action>,<bdf>,<action>,...";

Note: the env var has priority over the device tree property.

For example, given this configuration on bus 6:

=> pci 6
Scanning PCI devices on bus 6
BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
_____________________________________________________________
06.00.00   0x8086     0x1572     Network controller      0x00
06.00.01   0x8086     0x1572     Network controller      0x00

The following u-boot env var will create iommu mappings for 3 VFs for each PF:

=> setenv pci_iommu_extra pci@0x3800000,6.0.0,vfs=3,6.0.1,vfs=3

For the device tree case, this would be specified like this:

pci-iommu-extra = "6.0.0,vfs=3,6.0.1,vfs=3";

To add an iommu mapping for a hot-plugged device, please see following example:

=> setenv pci_iommu_extra pci@0x3800000,2.16.0,hp

For the device tree case, this would be specified like this:

pci-iommu-extra = "2.16.0,hp";

QSPI Boot source support Overview
-------------------
	1. LS1043A
		LS1043AQDS
	2. LS2080A
		LS2080AQDS
	3. LS1012A
		LS1012AQDS
		LS1012ARDB
	4. LS1046A
		LS1046AQDS
		LS1046ARDB

Booting from QSPI
-------------------
Booting from QSPI requires two images, RCW and u-boot-dtb.bin.
The difference between QSPI boot RCW image and NOR boot image is the PBI
command sequence for setting the boot location pointer. It's should point
to the address for u-boot in QSPI flash.

RCW image should be written to the beginning of QSPI flash device.
Example of using u-boot command

=> sf probe 0:0
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB
=> sf erase 0 +<size of rcw image>
SF: 65536 bytes @ 0x0 Erased: OK
=> sf write <rcw image in memory> 0 <size of rcw image>
SF: 164 bytes @ 0x0 Written: OK

To get the QSPI image, build u-boot with QSPI config, for example,
<board_name>_qspi_defconfig. The image needed is u-boot-dtb.bin.
The u-boot image should be written to 0x10000(but 0x1000 for LS1043A, LS2080A).

=> sf probe 0:0
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB
=> sf erase 10000 +<size of u-boot image>
SF: 589824 bytes @ 0x10000 Erased: OK
=> sf write <u-boot image in memory> 10000 <size of u-boot image>
SF: 580966 bytes @ 0x10000 Written: OK

With these two images in QSPI flash device, the board can boot from QSPI.

SoC overview

	1. LS1043A
	2. LS1088A
	3. LS2080A
	4. LS1012A
	5. LS1046A
	6. LS2088A
	7. LS2081A
	8. LX2160A
	9. LS1028A
	10. LX2162A

LS1043A
---------
The LS1043A integrated multicore processor combines four ARM Cortex-A53
processor cores with datapath acceleration optimized for L2/3 packet
processing, single pass security offload and robust traffic management
and quality of service.

The LS1043A SoC includes the following function and features:
 - Four 64-bit ARM Cortex-A53 CPUs
 - 1 MB unified L2 Cache
 - One 32-bit DDR3L/DDR4 SDRAM memory controllers with ECC and interleaving
   support
 - Data Path Acceleration Architecture (DPAA) incorporating acceleration the
   the following functions:
   - Packet parsing, classification, and distribution (FMan)
   - Queue management for scheduling, packet sequencing, and congestion
     management (QMan)
   - Hardware buffer management for buffer allocation and de-allocation (BMan)
   - Cryptography acceleration (SEC)
 - Ethernet interfaces by FMan
   - Up to 1 x XFI supporting 10G interface
   - Up to 1 x QSGMII
   - Up to 4 x SGMII supporting 1000Mbps
   - Up to 2 x SGMII supporting 2500Mbps
   - Up to 2 x RGMII supporting 1000Mbps
 - High-speed peripheral interfaces
   - Three PCIe 2.0 controllers, one supporting x4 operation
   - One serial ATA (SATA 3.0) controllers
 - Additional peripheral interfaces
   - Three high-speed USB 3.0 controllers with integrated PHY
   - Enhanced secure digital host controller (eSDXC/eMMC)
   - Quad Serial Peripheral Interface (QSPI) Controller
   - Serial peripheral interface (SPI) controller
   - Four I2C controllers
   - Two DUARTs
   - Integrated flash controller supporting NAND and NOR flash
 - QorIQ platform's trust architecture 2.1

LS1088A
--------
The QorIQ LS1088A processor is built on the Layerscape
architecture combining eight ARM A53 processor cores
with advanced, high-performance datapath acceleration
and networks, peripheral interfaces required for
networking, wireless infrastructure, and general-purpose
embedded applications.

LS1088A is compliant with the Layerscape Chassis Generation 3.

Features summary:
 - 8 32-bit / 64-bit ARM v8 Cortex-A53 CPUs
 - Cores are in 2 cluster of 4-cores each
 - 1MB L2 - Cache per cluster
 - Cache coherent interconnect (CCI-400)
 - 1 64-bit DDR4 SDRAM memory controller with ECC
 - Data path acceleration architecture 2.0 (DPAA2)
 - 4-Lane 10GHz SerDes comprising of WRIOP
 - 4-Lane 10GHz SerDes comprising of PCI, SATA, uQE(TDM/HLDC/UART)
 - Ethernet interfaces: SGMIIs, RGMIIs, QSGMIIs, XFIs
 - QSPI, SPI, IFC2.0 supporting NAND, NOR flash
 - 3 PCIe3.0 , 1 SATA3.0, 2 USB3.0, 1 SDXC, 2 DUARTs etc
 - 2 DUARTs
 - 4 I2C, GPIO
 - Thermal monitor unit(TMU)
 - 4 Flextimers and 1 generic timer
 - Support for hardware virtualization and partitioning enforcement
 - QorIQ platform's trust architecture 3.0
 - Service processor (SP) provides pre-boot initialization and secure-boot
   capabilities

LS2080A
--------
The LS2080A integrated multicore processor combines eight ARM Cortex-A57
processor cores with high-performance data path acceleration logic and network
and peripheral bus interfaces required for networking, telecom/datacom,
wireless infrastructure, and mil/aerospace applications.

The LS2080A SoC includes the following function and features:

 - Eight 64-bit ARM Cortex-A57 CPUs
 - 1 MB platform cache with ECC
 - Two 64-bit DDR4 SDRAM memory controllers with ECC and interleaving support
 - One secondary 32-bit DDR4 SDRAM memory controller, intended for use by
  the AIOP
 - Data path acceleration architecture (DPAA2) incorporating acceleration for
 the following functions:
   - Packet parsing, classification, and distribution (WRIOP)
   - Queue and Hardware buffer management for scheduling, packet sequencing, and
     congestion management, buffer allocation and de-allocation (QBMan)
   - Cryptography acceleration (SEC) at up to 10 Gbps
   - RegEx pattern matching acceleration (PME) at up to 10 Gbps
   - Decompression/compression acceleration (DCE) at up to 20 Gbps
   - Accelerated I/O processing (AIOP) at up to 20 Gbps
   - QDMA engine
 - 16 SerDes lanes at up to 10.3125 GHz
 - Ethernet interfaces
   - Up to eight 10 Gbps Ethernet MACs
   - Up to eight 1 / 2.5 Gbps Ethernet MACs
 - High-speed peripheral interfaces
   - Four PCIe 3.0 controllers, one supporting SR-IOV
 - Additional peripheral interfaces
   - Two serial ATA (SATA 3.0) controllers
   - Two high-speed USB 3.0 controllers with integrated PHY
   - Enhanced secure digital host controller (eSDXC/eMMC)
   - Serial peripheral interface (SPI) controller
   - Quad Serial Peripheral Interface (QSPI) Controller
   - Four I2C controllers
   - Two DUARTs
   - Integrated flash controller (IFC 2.0) supporting NAND and NOR flash
 - Support for hardware virtualization and partitioning enforcement
 - QorIQ platform's trust architecture 3.0
 - Service processor (SP) provides pre-boot initialization and secure-boot
  capabilities

LS1012A
--------
The LS1012A features an advanced 64-bit ARM v8 Cortex-
A53 processor, with 32 KB of parity protected L1-I cache,
32 KB of ECC protected L1-D cache, as well as 256 KB of
ECC protected L2 cache.

The LS1012A SoC includes the following function and features:
 - One 64-bit ARM v8 Cortex-A53 core with the following capabilities:
 - ARM v8 cryptography extensions
 - One 16-bit DDR3L SDRAM memory controller, Up to 1.0 GT/s, Supports
    16-/8-bit operation (no ECC support)
 - ARM core-link CCI-400 cache coherent interconnect
 - Packet Forwarding Engine (PFE)
 - Cryptography acceleration (SEC)
 - Ethernet interfaces supported by PFE:
 - One Configurable x3 SerDes:
    Two Serdes PLLs supported for usage by any SerDes data lane
    Support for up to 6 GBaud operation
 - High-speed peripheral interfaces:
     - One PCI Express Gen2 controller, supporting x1 operation
     - One serial ATA (SATA Gen 3.0) controller
     - One USB 3.0/2.0 controller with integrated PHY
     - One USB 2.0 controller with ULPI interface. .
 - Additional peripheral interfaces:
    - One quad serial peripheral interface (QuadSPI) controller
    - One serial peripheral interface (SPI) controller
    - Two enhanced secure digital host controllers
    - Two I2C controllers
    - One 16550 compliant DUART (two UART interfaces)
    - Two general purpose IOs (GPIO)
    - Two FlexTimers
    - Five synchronous audio interfaces (SAI)
    - Pre-boot loader (PBL) provides pre-boot initialization and RCW loading
    - Single-source clocking solution enabling generation of core, platform,
    DDR, SerDes, and USB clocks from a single external crystal and internal
    crystaloscillator
    - Thermal monitor unit (TMU) with +/- 3C accuracy
    - Two WatchDog timers
    - ARM generic timer
 - QorIQ platform's trust architecture 2.1

LS1046A
--------
The LS1046A integrated multicore processor combines four ARM Cortex-A72
processor cores with datapath acceleration optimized for L2/3 packet
processing, single pass security offload and robust traffic management
and quality of service.

The LS1046A SoC includes the following function and features:
 - Four 64-bit ARM Cortex-A72 CPUs
 - 2 MB unified L2 Cache
 - One 64-bit DDR4 SDRAM memory controllers with ECC and interleaving
   support
 - Data Path Acceleration Architecture (DPAA) incorporating acceleration the
   the following functions:
   - Packet parsing, classification, and distribution (FMan)
   - Queue management for scheduling, packet sequencing, and congestion
     management (QMan)
   - Hardware buffer management for buffer allocation and de-allocation (BMan)
   - Cryptography acceleration (SEC)
 - Two Configurable x4 SerDes
   - Two PLLs per four-lane SerDes
   - Support for 10G operation
 - Ethernet interfaces by FMan
   - Up to 2 x XFI supporting 10G interface (MAC 9, 10)
   - Up to 1 x QSGMII (MAC 5, 6, 10, 1)
   - Up to 4 x SGMII supporting 1000Mbps (MAC 5, 6, 9, 10)
   - Up to 3 x SGMII supporting 2500Mbps (MAC 5, 9, 10)
   - Up to 2 x RGMII supporting 1000Mbps (MAC 3, 4)
 - High-speed peripheral interfaces
   - Three PCIe 3.0 controllers, one supporting x4 operation
   - One serial ATA (SATA 3.0) controllers
 - Additional peripheral interfaces
   - Three high-speed USB 3.0 controllers with integrated PHY
   - Enhanced secure digital host controller (eSDXC/eMMC)
   - Quad Serial Peripheral Interface (QSPI) Controller
   - Serial peripheral interface (SPI) controller
   - Four I2C controllers
   - Two DUARTs
   - Integrated flash controller (IFC) supporting NAND and NOR flash
 - QorIQ platform's trust architecture 2.1

LS2088A
--------
The LS2088A integrated multicore processor combines eight ARM Cortex-A72
processor cores with high-performance data path acceleration logic and network
and peripheral bus interfaces required for networking, telecom/datacom,
wireless infrastructure, and mil/aerospace applications.

The LS2088A SoC includes the following function and features:

 - Eight 64-bit ARM Cortex-A72 CPUs
 - 1 MB platform cache with ECC
 - Two 64-bit DDR4 SDRAM memory controllers with ECC and interleaving support
 - One secondary 32-bit DDR4 SDRAM memory controller, intended for use by
   the AIOP
 - Data path acceleration architecture (DPAA2) incorporating acceleration for
   the following functions:
   - Packet parsing, classification, and distribution (WRIOP)
   - Queue and Hardware buffer management for scheduling, packet sequencing, and
     congestion management, buffer allocation and de-allocation (QBMan)
   - Cryptography acceleration (SEC) at up to 10 Gbps
   - RegEx pattern matching acceleration (PME) at up to 10 Gbps
   - Decompression/compression acceleration (DCE) at up to 20 Gbps
   - Accelerated I/O processing (AIOP) at up to 20 Gbps
   - QDMA engine
 - 16 SerDes lanes at up to 10.3125 GHz
 - Ethernet interfaces
   - Up to eight 10 Gbps Ethernet MACs
   - Up to eight 1 / 2.5 Gbps Ethernet MACs
 - High-speed peripheral interfaces
   - Four PCIe 3.0 controllers, one supporting SR-IOV
 - Additional peripheral interfaces
   - Two serial ATA (SATA 3.0) controllers
   - Two high-speed USB 3.0 controllers with integrated PHY
   - Enhanced secure digital host controller (eSDXC/eMMC)
   - Serial peripheral interface (SPI) controller
   - Quad Serial Peripheral Interface (QSPI) Controller
   - Four I2C controllers
   - Two DUARTs
   - Integrated flash controller (IFC 2.0) supporting NAND and NOR flash
 - Support for hardware virtualization and partitioning enforcement
 - QorIQ platform's trust architecture 3.0
 - Service processor (SP) provides pre-boot initialization and secure-boot
 capabilities

LS2088A SoC has 3 more similar SoC personalities
1)LS2048A, few difference w.r.t. LS2088A:
       a) Four 64-bit ARM v8 Cortex-A72 CPUs

2)LS2084A, few difference w.r.t. LS2088A:
       a) No AIOP
       b) No 32-bit DDR3 SDRAM memory
       c) 5 * 1/10G + 5 *1G WRIOP
       d) No L2 switch

3)LS2044A, few difference w.r.t. LS2084A:
       a) Four 64-bit ARM v8 Cortex-A72 CPUs

LS2081A
--------
LS2081A is 40-pin derivative of LS2084A.
So feature-wise it is same as LS2084A.
Refer to LS2084A(LS2088A) section above for details.

It has one more similar SoC personality
1)LS2041A, few difference w.r.t. LS2081A:
       a) Four 64-bit ARM v8 Cortex-A72 CPUs

LX2160A
--------
The QorIQ LX2160A processor is built in the 16FFC process on
the Layerscape architecture combining sixteen ARM A72 processor
cores with advanced, high-performance datapath acceleration and
network, peripheral interfaces required for networking, wireless
infrastructure, storage, and general-purpose embedded applications.

LX2160A is compliant with the Layerscape Chassis Generation 3.2.

The LX2160A SoC includes the following function and features:
  Sixteen 32-bit / 64-bit ARM v8 A72 CPUs
  Cache Coherent Interconnect Fabric (CCN508 aka “Eliot”)
  Two 64-bit 3.2GT/s DDR4 SDRAM memory controllers with ECC.
  Data path acceleration architecture (DPAA2)
  24 Serdes lanes at up to 25 GHz
  Ethernet interfaces
  Single WRIOP tile supporting 130Gbps using 18 MACs
  Support for 10G-SXGMII (aka USXGMII).
  Support for SGMII (and 1000Base-KX)
  Support for XFI (and 10GBase-KR)
  Support for CAUI4 (100G); CAUI2 (50G) and 25G-AUI(25G).
  Support for XLAUI (and 40GBase-KR4) for 40G.
  Support for two RGMII parallel interfaces.
  Energy efficient Ethernet support (802.3az)
  IEEE 1588 support.
  High-speed peripheral interfaces
	Two PCIe Gen 4.0 8-lane controllers supporting SR-IOV,
	Four PCIe Gen 4.0 4-lane controllers.
	Four serial ATA (SATA 3.0) controllers.
	Two USB 3.0 controllers with integrated PHY
	Two Enhanced secure digital host controllers
	Two Controller Area Network (CAN) modules
	Flexible Serial peripheral interface (FlexSPI) controller.
	Three Serial peripheral interface (SPI) controllers.
	Eight I2C Controllers.
	Four PL011 UARTs supporting two 4-pin UART ports or four 2-pin UART ports.
	General Purpose IO (GPIO)
  Support for hardware virtualization and partitioning (ARM MMU-500)
  Support for GIC (ARM GIC-500)
  QorIQ platform Trust Architecture 3.0
  One Secure WatchDog timer and one Non-Secure Watchdog timer.
  ARM Generic Timer
  Two Flextimers
  Debug supporting run control, data acquisition, high-speed trace,
  performance/event monitoring
  Thermal Monitor Unit (TMU) with +/- 2C accuracy
  Support for Voltage ID (VID) for yield improvement

LX2160A SoC has 2 more similar SoC personalities
1)LX2120A, few difference w.r.t. LX2160A:
       a) Twelve 64-bit ARM v8 Cortex-A72 CPUs

2)LX2080A, few difference w.r.t. LX2160A:
       a) Eight 64-bit ARM v8 Cortex-A72 CPUs


LS1028A
--------
The QorIQ LS1028A processor integrates two 64-bit Arm Cortex-A72 cores with
a GPU and LCD controller, as well as two TSN-enabled Ethernet controllers and
a TSNenabled 4-port switch.

The high performance Cortex-A72 cores, performing above 16,000 CoreMarks,
combined with 2.5 Gbit Ethernet, PCI express Gen 3.0, SATA 3.0, USB 3.0 and
Octal/Quad SPI interfaces provide capabilities for a number of industrial and
embedded applications. The device provides excellent integration with the
new Time-Sensitive Networking standard, and enables a number of
TSN applications.

The LS1028A SoC includes the following function and features:
 - Two 64-bit ARM v8 A72 CPUs
 - Cache Coherent interconnect (CCI-400)
 - One 32-bit DDR3L/DDR4 SDRAM memory controller with ECC
 - eDP/Displayport interface
 - Graphics processing unit
 - One Configurable x4 SerDes
 - Ethernet interfaces
   - Non-switched: One Ethernet MAC supporting 2.5G, 1G, 100M, 10M, one
   ethernet MAC supporting 1G, 100M, 10M.
   - Switched: TSN IP to support four 2.5/1G interfaces.
   - None of the MACs support MACSEC
   - Support for RGMII, SGMII (and 1000Base-KX), SGMII 2.5x, QSGMII
   - Support for 10G-SXGMII and 10G-QXGMII.
   - Energy efficient Ethernet support (802.3az)
   - IEEE 1588 support
  - High-speed peripheral interfaces
    - Two PCIe 3.0 controllers, one supporting x4 operation
    - One serial ATA (SATA 3.0) controller
  - Additional peripheral interfaces
    - Two high-speed USB 2.0/3.0 controllers with integrated PHY each
      supporting host or device modes
    - Two Enhanced secure digital host controllers (SD/SDIO/eMMC)
    - Two Serial peripheral interface (SPI) controllers
    - Eight I2C controllers
    - Two UART controllers
    - Additional six Industrual UARTs (LPUART).
    - One FlexSPI controller
    - General Purpose IO (GPIO)
    - Two CAN-FD interfaces
    - Eight Flextimers with PWM I/O
  - Support for hardware virtualization and partitioning enforcement
  - Layerscape Trust Architecture
  - Service Processor (SP) provides pre-boot initialization and secure-boot
    capabilities

LX2162A
--------
The QorIQ LX2162A processor is built on the Layerscape architecture
combining sixteen ARM A72 processor cores with advanced, high-performance
datapath acceleration and network, peripheral interfaces required for
networking, wireless infrastructure, storage, and general-purpose embedded
applications.

LX2162A is compliant with the Layerscape Chassis Generation 3.2.

The LX2162A SoC includes the following function and features:
  Sixteen 32-bit / 64-bit ARM v8 A72 CPUs
  Cache Coherent Interconnect Fabric (CCN508)
  One 64-bit 2.9GT/s DDR4 SDRAM memory controllers with ECC.
  Data path acceleration architecture (DPAA2)
  12 Serdes lanes at up to 25 GHz
  Ethernet interfaces
  Support for 10G-SXGMII (aka USXGMII).
  Support for SGMII (and 1000Base-KX)
  Support for XFI (and 10GBase-KR)
  Support for CAUI2 (50G) and 25G-AUI(25G).
  Support for XLAUI (and 40GBase-KR4) for 40G.
  Support for two RGMII parallel interfaces.
  Energy efficient Ethernet support (802.3az)
  IEEE 1588 support.
  High-speed peripheral interfaces
	One PCIe Gen 3.0 8-lane controllers supporting SR-IOV,
	Two PCIe Gen 3.0 4-lane controllers.
	Four serial ATA (SATA 3.0) controllers.
	One USB 3.0 controllers with integrated PHY
	Two Enhanced secure digital host controllers
	Two Controller Area Network (CAN) modules
	Flexible Serial peripheral interface (FlexSPI) controller.
	Three Serial peripheral interface (SPI) controllers.
	Eight I2C Controllers.
	Four PL011 UARTs supporting two 4-pin UART ports or four 2-pin UART ports.
	General Purpose IO (GPIO)
  Support for hardware virtualization and partitioning (ARM MMU-500)
  Support for GIC (ARM GIC-500)
  QorIQ platform Trust Architecture 3.0
  One Secure WatchDog timer and one Non-Secure Watchdog timer.
  ARM Generic Timer
  Two Flextimers
  Debug supporting run control, data acquisition, high-speed trace,
  performance/event monitoring
  Thermal Monitor Unit (TMU) with +/- 2C accuracy
  Support for Voltage ID (VID) for yield improvement

LX2162A SoC has 2 more similar SoC personalities
1)LX2122A, few difference w.r.t. LX2162A:
       a) Twelve 64-bit ARM v8 Cortex-A72 CPUs

2)LX2082A, few difference w.r.t. LX2162A:
       a) Eight 64-bit ARM v8 Cortex-A72 CPUs