diff options
Diffstat (limited to 'roms/u-boot/arch/arm/cpu/armv8/fsl-layerscape/doc')
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 |