Add submodule dependency filesHEADmaster

Change-Id: Iaf8d18082d3991dec7c0ebbea540f092188eb4ec

8 files changed, 1163 insertions, 0 deletions

diff --git a/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
new file mode 100644
index 000000000..85cf6abd6
--- /dev/null
+++ b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.core_prefetch
@@ -0,0 +1,20 @@
+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.
diff --git a/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon
new file mode 100644
index 000000000..b3c6693a4
--- /dev/null
+++ b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon
@@ -0,0 +1,150 @@
+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.
diff --git a/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
new file mode 100644
index 000000000..d7f7b9f11
--- /dev/null
+++ b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2
@@ -0,0 +1,20 @@
+#
+# 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.
diff --git a/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3 b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
new file mode 100644
index 000000000..6c98d99d0
--- /dev/null
+++ b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
@@ -0,0 +1,400 @@
+#
+# 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
diff --git a/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3_2 b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3_2
new file mode 100644
index 000000000..6d4bd0b80
--- /dev/null
+++ b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3_2
@@ -0,0 +1,27 @@
+#
+# 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
diff --git a/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra
new file mode 100644
index 000000000..43db4d8e9
--- /dev/null
+++ b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra
@@ -0,0 +1,67 @@
+#
+# 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";
diff --git a/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.qspi b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.qspi
new file mode 100644
index 000000000..de86f4b30
--- /dev/null
+++ b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.qspi
@@ -0,0 +1,42 @@
+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.
diff --git a/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc
new file mode 100644
index 000000000..f33d05d05
--- /dev/null
+++ b/roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc
@@ -0,0 +1,437 @@
+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