Name |
Date |
Size |
#Lines |
LOC |
||
---|---|---|---|---|---|---|
.. | - | - | ||||
README.core_prefetch | H A D | 07-Dec-2017 | 745 | 21 | 17 | |
README.falcon | H A D | 23-Aug-2018 | 6.5 KiB | 151 | 131 | |
README.lsch2 | H A D | 01-Jan-2019 | 718 | 22 | 18 | |
README.lsch3 | H A D | 18-Dec-2017 | 16.5 KiB | 401 | 330 | |
README.lsch3_2 | H A D | 10-Dec-2018 | 694 | 28 | 20 | |
README.qspi | H A D | 29-Nov-2016 | 1.4 KiB | 43 | 36 | |
README.soc | H A D | 10-Dec-2018 | 13.3 KiB | 331 | 304 |
README.core_prefetch
1Core instruction prefetch disable 2--------------------------------- 3To disable instruction prefetch of core; hwconfig needs to be updated. 4for e.g. 5setenv hwconfig 'fsl_ddr:bank_intlv=auto;core_prefetch:disable=0x02' 6 7Here 0x02 can be replaced with any valid value except Mask[0] bit. It 8represents 64 bit mask. The 64-bit Mask has one bit for each core. 9Mask[0] = core0 10Mask[1] = core1 11Mask[2] = core2 12etc 13If the bit is set ('b1) in the mask, then prefetch is disabled for 14that core when it is released from reset. 15 16core0 prefetch should not be disabled i.e. Mask[0] should never be set. 17Setting Mask[0] may lead to undefined behavior. 18 19Once disabled, prefetch remains disabled until the next reset. 20There is no function to re-enable prefetch. 21
README.falcon
1Falcon boot option 2------------------ 3Falcon boot is a short cut boot method for SD/eMMC targets. It skips loading the 4RAM version U-Boot. Instead, it loads FIT image and boot directly to Linux. 5CONFIG_SPL_OS_BOOT enables falcon boot. CONFIG_SPL_LOAD_FIT enables the FIT 6image support (also need CONFIG_SPL_OF_LIBFDT, CONFIG_SPL_FIT and optionally 7CONFIG_SPL_GZIP). 8 9To enable falcon boot, a hook function spl_start_uboot() returns 0 to indicate 10booting U-Boot is not the first choice. The kernel FIT image needs to be put 11at CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR. SPL mmc driver reads the header to 12determine if this is a FIT image. If true, FIT image components are parsed and 13copied or decompressed (if applicable) to their destinations. If FIT image is 14not found, normal U-Boot flow will follow. 15 16An important part of falcon boot is to prepare the device tree. A normal U-Boot 17does FDT fixups when booting Linux. For falcon boot, Linux boots directly from 18SPL, skipping the normal U-Boot. The device tree has to be prepared in advance. 19A command "spl export" should be called under the normal RAM version U-Boot. 20It is equivalent to go through "bootm" step-by-step until device tree fixup is 21done. The device tree in memory is the one needed for falcon boot. Falcon boot 22flow suggests to save this image to SD/eMMC at the location pointed by macro 23CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR, with maximum size specified by macro 24CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS. However, when FIT image is used for 25Linux, the device tree stored in FIT image overwrites the memory loaded by spl 26driver from these sectors. We could change this loading order to favor the 27stored sectors. But when secure boot is enabled, these sectors are used for 28signature header and needs to be loaded before the FIT image. So it is important 29to understand the device tree in FIT image should be the one actually used, or 30leave it absent to favor the stored sectors. It is easier to deploy the FIT 31image with embedded static device tree to multiple boards. 32 33Macro CONFIG_SYS_SPL_ARGS_ADDR serves two purposes. One is the pointer to load 34the stored sectors to. Normally this is the static device tree. The second 35purpose is the memory location of signature header for secure boot. After the 36FIT image is loaded into memory, it is validated against the signature header 37before individual components are extracted (and optionally decompressed) into 38their final memory locations, respectively. After the validation, the header 39is no longer used. The static device tree is copied into this location. So 40this macro is passed as the location of device tree when booting Linux. 41 42Steps to prepare static device tree 43----------------------------------- 44To prepare the static device tree for Layerscape boards, it is important to 45understand the fixups in U-Boot. Memory size and location, as well as reserved 46memory blocks are added/updated. Ethernet MAC addressed are updated. FMan 47microcode (if used) is embedded in the device tree. Kernel command line and 48initrd information are embedded. Others including CPU status, boot method, 49Ethernet port status, etc. are also updated. 50 51Following normal booting process, all variables are set, all images are loaded 52before "bootm" command would be issued to boot, run command 53 54spl export fdt <address> 55 56where the address is the location of FIT image. U-Boot goes through the booting 57process as if "bootm start", "bootm loados", "bootm ramdisk"... commands but 58stops before "bootm go". There we have the fixed-up device tree in memory. 59We can check the device tree header by these commands 60 61fdt addr <fdt address> 62fdt header 63 64Where the fdt address is the device tree in memory. It is printed by U-Boot. 65It is useful to know the exact size. One way to extract this static device 66tree is to save it to eMMC/SD using command in U-Boot, and extract under Linux 67with these commands, repectively 68 69mmc write <address> <sector> <sectors> 70dd if=/dev/mmcblk0 of=<filename> bs=512 skip=<sector> count=<sectors> 71 72Note, U-Boot takes values as hexadecimals while Linux takes them as decimals by 73default. If using NAND or other storage, the commands are slightly different. 74When we have the static device tree image, we can re-make the FIT image with 75it. It is important to specify the load addresses in FIT image for every 76components. Otherwise U-Boot cannot load them correctly. 77 78Generate FIT image with static device tree 79------------------------------------------ 80Example: 81 82/dts-v1/; 83 84/ { 85 description = "Image file for the LS1043A Linux Kernel"; 86 #address-cells = <1>; 87 88 images { 89 kernel { 90 description = "ARM64 Linux kernel"; 91 data = /incbin/("./arch/arm64/boot/Image.gz"); 92 type = "kernel"; 93 arch = "arm64"; 94 os = "linux"; 95 compression = "gzip"; 96 load = <0x80080000>; 97 entry = <0x80080000>; 98 }; 99 fdt-1 { 100 description = "Flattened Device Tree blob"; 101 data = /incbin/("./fsl-ls1043ardb-static.dtb"); 102 type = "flat_dt"; 103 arch = "arm64"; 104 compression = "none"; 105 load = <0x90000000>; 106 }; 107 ramdisk { 108 description = "LS1043 Ramdisk"; 109 data = /incbin/("./rootfs.cpio.gz"); 110 type = "ramdisk"; 111 arch = "arm64"; 112 os = "linux"; 113 compression = "none"; 114 load = <0xa0000000>; 115 }; 116 }; 117 118 configurations { 119 default = "config-1"; 120 config-1 { 121 description = "Boot Linux kernel"; 122 kernel = "kernel"; 123 fdt = "fdt-1"; 124 ramdisk = "ramdisk"; 125 loadables = "fdt", "ramdisk"; 126 }; 127 }; 128}; 129 130The "loadables" is not optional. It tells SPL which images to load into memory. 131 132Falcon mode with QSPI boot 133-------------------------- 134To use falcon mode with QSPI boot, SPL needs to be enabled. Similar to SD or 135NAND boot, a RAM version full feature U-Boot is needed. Unlike SD or NAND boot, 136SPL with QSPI doesn't need to combine SPL image with RAM version image. Two 137separated images are used, u-boot-spl.pbl and u-boot.img. The former is SPL 138image with RCW and PBI commands to load the SPL payload into On-Chip RAM. The 139latter is RAM version U-Boot in FIT format (or legacy format if FIT is not 140used). 141 142Other things to consider 143----------------------- 144Falcon boot skips a lot of initialization in U-Boot. If Linux expects the 145hardware to be initialized by U-Boot, the related code should be ported to SPL 146build. For example, if Linux expect Ethernet PHY to be initialized in U-Boot 147(which is not a common case), the PHY initialization has to be included in 148falcon boot. This increases the SPL image size and should be handled carefully. 149If Linux has PHY driver enabled, it still depends on the correct MDIO bus setup 150in U-Boot. Normal U-Boot sets the MDC ratio to generate a proper clock signal. 151
README.lsch2
1# 2# Copyright 2015 Freescale Semiconductor 3# 4# SPDX-License-Identifier: GPL-2.0+ 5# 6 7Freescale LayerScape with Chassis Generation 2 8 9This architecture supports Freescale ARMv8 SoCs with Chassis generation 2, 10for example LS1043A. 11 12Watchdog support Overview 13------------------- 14Support watchdog driver for LSCH2. The driver is disabled in default. 15You can enable it by setting CONFIG_IMX_WATCHDOG. 16Use following config to set watchdog timeout, if this config is not defined, 17the default timeout value is 128s which is the maximum. Set 10 seconds for 18example: 19 #define CONFIG_WATCHDOG_TIMEOUT_MSECS 10000 20Set CONFIG_WATCHDOG_RESET_DISABLE to disable reset watchdog, so that the 21watchdog will not be fed in u-boot. 22
README.lsch3
1# 2# Copyright 2014-2015 Freescale Semiconductor 3# 4# SPDX-License-Identifier: GPL-2.0+ 5# 6 7Freescale LayerScape with Chassis Generation 3 8 9This architecture supports Freescale ARMv8 SoCs with Chassis generation 3, 10for example LS2080A. 11 12DDR Layout 13============ 14Entire DDR region splits into two regions. 15 - Region 1 is at address 0x8000_0000 to 0xffff_ffff. 16 - Region 2 is at 0x80_8000_0000 to the top of total memory, 17 for example 16GB, 0x83_ffff_ffff. 18 19All DDR memory is marked as cache-enabled. 20 21When MC and Debug server is enabled, they carve 512MB away from the high 22end of DDR. For example, if the total DDR is 16GB, it shrinks to 15.5GB 23with MC and Debug server enabled. Linux only sees 15.5GB. 24 25The reserved 512MB layout looks like 26 27 +---------------+ <-- top/end of memory 28 | 256MB | debug server 29 +---------------+ 30 | 256MB | MC 31 +---------------+ 32 | ... | 33 34MC requires the memory to be aligned with 512MB, so even debug server is 35not enabled, 512MB is reserved, not 256MB. 36 37Flash Layout 38============ 39 40(1) A typical layout of various images (including Linux and other firmware images) 41 is shown below considering a 32MB NOR flash device present on most 42 pre-silicon platforms (simulator and emulator): 43 44 ------------------------- 45 | FIT Image | 46 | (linux + DTB + RFS) | 47 ------------------------- ----> 0x0120_0000 48 | Debug Server FW | 49 ------------------------- ----> 0x00C0_0000 50 | AIOP FW | 51 ------------------------- ----> 0x0070_0000 52 | MC FW | 53 ------------------------- ----> 0x006C_0000 54 | MC DPL Blob | 55 ------------------------- ----> 0x0020_0000 56 | BootLoader + Env| 57 ------------------------- ----> 0x0000_1000 58 | PBI | 59 ------------------------- ----> 0x0000_0080 60 | RCW | 61 ------------------------- ----> 0x0000_0000 62 63 32-MB NOR flash layout for pre-silicon platforms (simulator and emulator) 64 65(2) A typical layout of various images (including Linux and other firmware images) 66 is shown below considering a 128MB NOR flash device present on QDS and RDB 67 boards: 68 ----------------------------------------- ----> 0x5_8800_0000 --- 69 | .. Unused .. (7M) | | 70 ----------------------------------------- ----> 0x5_8790_0000 | 71 | FIT Image (linux + DTB + RFS) (40M) | | 72 ----------------------------------------- ----> 0x5_8510_0000 | 73 | PHY firmware (2M) | | 74 ----------------------------------------- ----> 0x5_84F0_0000 | 64K 75 | Debug Server FW (2M) | | Alt 76 ----------------------------------------- ----> 0x5_84D0_0000 | Bank 77 | AIOP FW (4M) | | 78 ----------------------------------------- ----> 0x5_8490_0000 (vbank4) 79 | MC DPC Blob (1M) | | 80 ----------------------------------------- ----> 0x5_8480_0000 | 81 | MC DPL Blob (1M) | | 82 ----------------------------------------- ----> 0x5_8470_0000 | 83 | MC FW (4M) | | 84 ----------------------------------------- ----> 0x5_8430_0000 | 85 | BootLoader Environment (1M) | | 86 ----------------------------------------- ----> 0x5_8420_0000 | 87 | BootLoader (1M) | | 88 ----------------------------------------- ----> 0x5_8410_0000 | 89 | RCW and PBI (1M) | | 90 ----------------------------------------- ----> 0x5_8400_0000 --- 91 | .. Unused .. (7M) | | 92 ----------------------------------------- ----> 0x5_8390_0000 | 93 | FIT Image (linux + DTB + RFS) (40M) | | 94 ----------------------------------------- ----> 0x5_8110_0000 | 95 | PHY firmware (2M) | | 96 ----------------------------------------- ----> 0x5_80F0_0000 | 64K 97 | Debug Server FW (2M) | | Bank 98 ----------------------------------------- ----> 0x5_80D0_0000 | 99 | AIOP FW (4M) | | 100 ----------------------------------------- ----> 0x5_8090_0000 (vbank0) 101 | MC DPC Blob (1M) | | 102 ----------------------------------------- ----> 0x5_8080_0000 | 103 | MC DPL Blob (1M) | | 104 ----------------------------------------- ----> 0x5_8070_0000 | 105 | MC FW (4M) | | 106 ----------------------------------------- ----> 0x5_8030_0000 | 107 | BootLoader Environment (1M) | | 108 ----------------------------------------- ----> 0x5_8020_0000 | 109 | BootLoader (1M) | | 110 ----------------------------------------- ----> 0x5_8010_0000 | 111 | RCW and PBI (1M) | | 112 ----------------------------------------- ----> 0x5_8000_0000 --- 113 114 128-MB NOR flash layout for QDS and RDB boards 115 116Environment Variables 117===================== 118mcboottimeout: MC boot timeout in milliseconds. If this variable is not defined 119 the value CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS will be assumed. 120 121mcmemsize: MC DRAM block size in hex. If this variable is not defined, the value 122 CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE will be assumed. 123 124mcinitcmd: This environment variable is defined to initiate MC and DPL deployment 125 from the location where it is stored(NOR, NAND, SD, SATA, USB)during 126 u-boot booting.If this variable is not defined then MC_BOOT_ENV_VAR 127 will be null and MC will not be booted and DPL will not be applied 128 during U-boot booting.However the MC, DPC and DPL can be applied from 129 console independently. 130 The variable needs to be set from the console once and then on 131 rebooting the parameters set in the variable will automatically be 132 executed. The commmand is demostrated taking an example of mc boot 133 using NOR Flash i.e. MC, DPL, and DPC is stored in the NOR flash: 134 135 cp.b 0xa0000000 0x580300000 $filesize 136 cp.b 0x80000000 0x580800000 $filesize 137 cp.b 0x90000000 0x580700000 $filesize 138 139 setenv mcinitcmd 'fsl_mc start mc 0x580300000 0x580800000' 140 141 If only linux is to be booted then the mcinitcmd environment should be set as 142 143 setenv mcinitcmd 'fsl_mc start mc 0x580300000 0x580800000;fsl_mc apply DPL 0x580700000' 144 145 Here the addresses 0xa0000000, 0x80000000, 0x80000000 are of DDR to where 146 MC binary, DPC binary and DPL binary are stored and 0x580300000, 0x580800000 147 and 0x580700000 are addresses in NOR where these are copied. It is to be 148 noted that these addresses in 'fsl_mc start mc 0x580300000 0x580800000;fsl_mc apply DPL 0x580700000' 149 can be replaced with the addresses of DDR to 150 which these will be copied in case of these binaries being stored in other 151 devices like SATA, USB, NAND, SD etc. 152 153Booting from NAND 154------------------- 155Booting from NAND requires two images, RCW and u-boot-with-spl.bin. 156The difference between NAND boot RCW image and NOR boot image is the PBI 157command sequence. Below is one example for PBI commands for LS2085AQDS which 158uses NAND device with 2KB/page, block size 128KB. 159 1601) CCSR 4-byte write to 0x00e00404, data=0x00000000 1612) CCSR 4-byte write to 0x00e00400, data=0x1800a000 162The above two commands set bootloc register to 0x00000000_1800a000 where 163the u-boot code will be running in OCRAM. 164 1653) Block Copy: SRC=0x0107, SRC_ADDR=0x00020000, DEST_ADDR=0x1800a000, 166BLOCK_SIZE=0x00014000 167This command copies u-boot image from NAND device into OCRAM. The values need 168to adjust accordingly. 169 170SRC should match the cfg_rcw_src, the reset config pins. It depends 171 on the NAND device. See reference manual for cfg_rcw_src. 172SRC_ADDR is the offset of u-boot-with-spl.bin image in NAND device. In 173 the example above, 128KB. For easy maintenance, we put it at 174 the beginning of next block from RCW. 175DEST_ADDR is fixed at 0x1800a000, matching bootloc set above. 176BLOCK_SIZE is the size to be copied by PBI. 177 178RCW image should be written to the beginning of NAND device. Example of using 179u-boot command 180 181nand write <rcw image in memory> 0 <size of rcw image> 182 183To form the NAND image, build u-boot with NAND config, for example, 184ls2080aqds_nand_defconfig. The image needed is u-boot-with-spl.bin. 185The u-boot image should be written to match SRC_ADDR, in above example 0x20000. 186 187nand write <u-boot image in memory> 200000 <size of u-boot image> 188 189With these two images in NAND device, the board can boot from NAND. 190 191Another example for LS2085ARDB boards, 192 1931) CCSR 4-byte write to 0x00e00404, data=0x00000000 1942) CCSR 4-byte write to 0x00e00400, data=0x1800a000 1953) Block Copy: SRC=0x0119, SRC_ADDR=0x00080000, DEST_ADDR=0x1800a000, 196BLOCK_SIZE=0x00014000 197 198nand write <rcw image in memory> 0 <size of rcw image> 199nand write <u-boot image in memory> 80000 <size of u-boot image> 200 201Notice the difference from QDS is SRC, SRC_ADDR and the offset of u-boot image 202to match board NAND device with 4KB/page, block size 512KB. 203 204Note, LS2088A and LS1088A don't support booting from NAND. 205 206Booting from SD/eMMC 207------------------- 208Booting from SD/eMMC requires two images, RCW and u-boot-with-spl.bin. 209The difference between SD boot RCW image and QSPI-NOR boot image is the 210PBI command sequence. Below is one example for PBI commands for RDB 211and QDS which uses SD device with block size 512. Block location can be 212calculated by dividing offset with block size. 213 2141) Block Copy: SRC=0x0040, SRC_ADDR=0x00100000, DEST_ADDR=0x1800a000, 215BLOCK_SIZE=0x00016000 216 217This command copies u-boot image from SD device into OCRAM. The values 218need to adjust accordingly for SD/eMMC 219 220SRC should match the cfg_rcw_src, the reset config pins. 221 The value for source(SRC) can be 0x0040 or 0x0041 222 depending upon SD or eMMC. 223SRC_ADDR is the offset of u-boot-with-spl.bin image in SD device. 224 In the example above, 1MB. This is same as QSPI-NOR. 225DEST_ADDR is configured at 0x1800a000, matching bootloc set above. 226BLOCK_SIZE is the size to be copied by PBI. 227 2282) CCSR 4-byte write to 0x01e00404, data=0x00000000 2293) CCSR 4-byte write to 0x01e00400, data=0x1800a000 230The above two commands set bootloc register to 0x00000000_1800a000 where 231the u-boot code will be running in OCRAM. 232 233 234RCW image should be written at 8th block of device(SD/eMMC). Example of 235using u-boot command 236 237mmc erase 0x8 0x10 238mmc write <rcw image in memory> 0x8 <size of rcw in block count typical value=10> 239 240To form the SD-Boot image, build u-boot with SD config, for example, 241ls1088ardb_sdcard_qspi_defconfig. The image needed is u-boot-with-spl.bin. 242The u-boot image should be written to match SRC_ADDR, in above example 243offset 0x100000 in other work it means block location 0x800 244 245mmc erase 0x800 0x1800 246mmc write <u-boot image in memory> 0x800 <size of u-boot image in block count> 247 248With these two images in SD/eMMC device, the board can boot from SD/eMMC. 249 250MMU Translation Tables 251====================== 252 253(1) Early MMU Tables: 254 255 Level 0 Level 1 Level 2 256------------------ ------------------ ------------------ 257| 0x00_0000_0000 | -----> | 0x00_0000_0000 | -----> | 0x00_0000_0000 | 258------------------ ------------------ ------------------ 259| 0x80_0000_0000 | --| | 0x00_4000_0000 | | 0x00_0020_0000 | 260------------------ | ------------------ ------------------ 261| invalid | | | 0x00_8000_0000 | | 0x00_0040_0000 | 262------------------ | ------------------ ------------------ 263 | | 0x00_c000_0000 | | 0x00_0060_0000 | 264 | ------------------ ------------------ 265 | | 0x01_0000_0000 | | 0x00_0080_0000 | 266 | ------------------ ------------------ 267 | ... ... 268 | ------------------ 269 | | 0x05_8000_0000 | --| 270 | ------------------ | 271 | | 0x05_c000_0000 | | 272 | ------------------ | 273 | ... | 274 | ------------------ | ------------------ 275 |--> | 0x80_0000_0000 | |-> | 0x00_3000_0000 | 276 ------------------ ------------------ 277 | 0x80_4000_0000 | | 0x00_3020_0000 | 278 ------------------ ------------------ 279 | 0x80_8000_0000 | | 0x00_3040_0000 | 280 ------------------ ------------------ 281 | 0x80_c000_0000 | | 0x00_3060_0000 | 282 ------------------ ------------------ 283 | 0x81_0000_0000 | | 0x00_3080_0000 | 284 ------------------ ------------------ 285 ... ... 286 287(2) Final MMU Tables: 288 289 Level 0 Level 1 Level 2 290------------------ ------------------ ------------------ 291| 0x00_0000_0000 | -----> | 0x00_0000_0000 | -----> | 0x00_0000_0000 | 292------------------ ------------------ ------------------ 293| 0x80_0000_0000 | --| | 0x00_4000_0000 | | 0x00_0020_0000 | 294------------------ | ------------------ ------------------ 295| invalid | | | 0x00_8000_0000 | | 0x00_0040_0000 | 296------------------ | ------------------ ------------------ 297 | | 0x00_c000_0000 | | 0x00_0060_0000 | 298 | ------------------ ------------------ 299 | | 0x01_0000_0000 | | 0x00_0080_0000 | 300 | ------------------ ------------------ 301 | ... ... 302 | ------------------ 303 | | 0x08_0000_0000 | --| 304 | ------------------ | 305 | | 0x08_4000_0000 | | 306 | ------------------ | 307 | ... | 308 | ------------------ | ------------------ 309 |--> | 0x80_0000_0000 | |--> | 0x08_0000_0000 | 310 ------------------ ------------------ 311 | 0x80_4000_0000 | | 0x08_0020_0000 | 312 ------------------ ------------------ 313 | 0x80_8000_0000 | | 0x08_0040_0000 | 314 ------------------ ------------------ 315 | 0x80_c000_0000 | | 0x08_0060_0000 | 316 ------------------ ------------------ 317 | 0x81_0000_0000 | | 0x08_0080_0000 | 318 ------------------ ------------------ 319 ... ... 320 321 322DPAA2 commands to manage Management Complex (MC) 323------------------------------------------------ 324DPAA2 commands has been introduced to manage Management Complex 325(MC). These commands are used to start mc, aiop and apply DPL 326from u-boot command prompt. 327 328Please note Management complex Firmware(MC), DPL and DPC are no 329more deployed during u-boot boot-sequence. 330 331Commands: 332a) fsl_mc start mc <FW_addr> <DPC_addr> - Start Management Complex 333b) fsl_mc apply DPL <DPL_addr> - Apply DPL file 334c) fsl_mc start aiop <FW_addr> - Start AIOP 335 336How to use commands :- 3371. Command sequence for u-boot ethernet: 338 a) fsl_mc start mc <FW_addr> <DPC_addr> - Start Management Complex 339 b) DPMAC net-devices are now available for use 340 341 Example- 342 Assumption: MC firmware, DPL and DPC dtb is already programmed 343 on NOR flash. 344 345 => fsl_mc start mc 580300000 580800000 346 => setenv ethact DPMAC1@xgmii 347 => ping $serverip 348 3492. Command sequence for Linux boot: 350 a) fsl_mc start mc <FW_addr> <DPC_addr> - Start Management Complex 351 b) fsl_mc apply DPL <DPL_addr> - Apply DPL file 352 c) No DPMAC net-devices are available for use in u-boot 353 d) boot Linux 354 355 Example- 356 Assumption: MC firmware, DPL and DPC dtb is already programmed 357 on NOR flash. 358 359 => fsl_mc start mc 580300000 580800000 360 => setenv ethact DPMAC1@xgmii 361 => tftp a0000000 kernel.itb 362 => fsl_mc apply dpl 580700000 363 => bootm a0000000 364 3653. Command sequence for AIOP boot: 366 a) fsl_mc start mc <FW_addr> <DPC_addr> - Start Management Complex 367 b) fsl_mc start aiop <FW_addr> - Start AIOP 368 c) fsl_mc apply DPL <DPL_addr> - Apply DPL file 369 d) No DPMAC net-devices are availabe for use in u-boot 370 Please note actual AIOP start will happen during DPL parsing of 371 Management complex 372 373 Example- 374 Assumption: MC firmware, DPL, DPC dtb and AIOP firmware is already 375 programmed on NOR flash. 376 377 => fsl_mc start mc 580300000 580800000 378 => fsl_mc start aiop 0x580900000 379 => setenv ethact DPMAC1@xgmii 380 => fsl_mc apply dpl 580700000 381 382Errata A009635 383--------------- 384If the core runs at higher than x3 speed of the platform, there is 385possiblity about sev instruction to getting missed by other cores. 386This is because of SoC Run Control block may not able to sample 387the EVENTI(Sev) signals. 388 389Workaround: Configure Run Control and EPU to periodically send out EVENTI signals to 390wake up A57 cores 391 392Errata workaround uses Env variable "a009635_interval_val". It uses decimal 393value. 394- Default value of env variable is platform clock (MHz) 395 396- User can modify default value by updating the env variable 397 setenv a009635_interval_val 600; saveenv; 398 It configure platform clock as 600 MHz 399 400- Env variable as 0 signifies no workaround 401
README.lsch3_2
1# 2# Copyright 2018 NXP 3# 4# SPDX-License-Identifier: GPL-2.0+ 5# 6 7NXP LayerScape with Chassis Generation 3.2 8 9This architecture supports NXP ARMv8 SoCs with Chassis generation 3.2 10for example LX2160A. 11 12This architecture is enhancement over Chassis Generation 3 with 13few differences mentioned below 14 151)DDR Layout 16============ 17Entire DDR region splits into three regions. 18 - Region 1 is at address 0x8000_0000 to 0xffff_ffff. 19 - Region 2 is at address 0x20_8000_0000 to 0x3f_ffff_ffff, 20 - Region 3 is at address 0x60_0000_0000 to the top of memory, 21 for example 140GB, 0x63_7fff_ffff. 22 23All DDR memory is marked as cache-enabled. 24 252)IFC is removed 26 273)Number of I2C controllers increased to 8 28
README.qspi
1QSPI Boot source support Overview 2------------------- 3 1. LS1043A 4 LS1043AQDS 5 2. LS2080A 6 LS2080AQDS 7 3. LS1012A 8 LS1012AQDS 9 LS1012ARDB 10 4. LS1046A 11 LS1046AQDS 12 LS1046ARDB 13 14Booting from QSPI 15------------------- 16Booting from QSPI requires two images, RCW and u-boot-dtb.bin. 17The difference between QSPI boot RCW image and NOR boot image is the PBI 18command sequence for setting the boot location pointer. It's should point 19to the address for u-boot in QSPI flash. 20 21RCW image should be written to the beginning of QSPI flash device. 22Example of using u-boot command 23 24=> sf probe 0:0 25SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB 26=> sf erase 0 +<size of rcw image> 27SF: 65536 bytes @ 0x0 Erased: OK 28=> sf write <rcw image in memory> 0 <size of rcw image> 29SF: 164 bytes @ 0x0 Written: OK 30 31To get the QSPI image, build u-boot with QSPI config, for example, 32<board_name>_qspi_defconfig. The image needed is u-boot-dtb.bin. 33The u-boot image should be written to 0x10000(but 0x1000 for LS1043A, LS2080A). 34 35=> sf probe 0:0 36SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB 37=> sf erase 10000 +<size of u-boot image> 38SF: 589824 bytes @ 0x10000 Erased: OK 39=> sf write <u-boot image in memory> 10000 <size of u-boot image> 40SF: 580966 bytes @ 0x10000 Written: OK 41 42With these two images in QSPI flash device, the board can boot from QSPI. 43
README.soc
1SoC overview 2 3 1. LS1043A 4 2. LS1088A 5 3. LS2080A 6 4. LS1012A 7 5. LS1046A 8 6. LS2088A 9 7. LS2081A 10 8. LX2160A 11 12LS1043A 13--------- 14The LS1043A integrated multicore processor combines four ARM Cortex-A53 15processor cores with datapath acceleration optimized for L2/3 packet 16processing, single pass security offload and robust traffic management 17and quality of service. 18 19The LS1043A SoC includes the following function and features: 20 - Four 64-bit ARM Cortex-A53 CPUs 21 - 1 MB unified L2 Cache 22 - One 32-bit DDR3L/DDR4 SDRAM memory controllers with ECC and interleaving 23 support 24 - Data Path Acceleration Architecture (DPAA) incorporating acceleration the 25 the following functions: 26 - Packet parsing, classification, and distribution (FMan) 27 - Queue management for scheduling, packet sequencing, and congestion 28 management (QMan) 29 - Hardware buffer management for buffer allocation and de-allocation (BMan) 30 - Cryptography acceleration (SEC) 31 - Ethernet interfaces by FMan 32 - Up to 1 x XFI supporting 10G interface 33 - Up to 1 x QSGMII 34 - Up to 4 x SGMII supporting 1000Mbps 35 - Up to 2 x SGMII supporting 2500Mbps 36 - Up to 2 x RGMII supporting 1000Mbps 37 - High-speed peripheral interfaces 38 - Three PCIe 2.0 controllers, one supporting x4 operation 39 - One serial ATA (SATA 3.0) controllers 40 - Additional peripheral interfaces 41 - Three high-speed USB 3.0 controllers with integrated PHY 42 - Enhanced secure digital host controller (eSDXC/eMMC) 43 - Quad Serial Peripheral Interface (QSPI) Controller 44 - Serial peripheral interface (SPI) controller 45 - Four I2C controllers 46 - Two DUARTs 47 - Integrated flash controller supporting NAND and NOR flash 48 - QorIQ platform's trust architecture 2.1 49 50LS1088A 51-------- 52The QorIQ LS1088A processor is built on the Layerscape 53architecture combining eight ARM A53 processor cores 54with advanced, high-performance datapath acceleration 55and networks, peripheral interfaces required for 56networking, wireless infrastructure, and general-purpose 57embedded applications. 58 59LS1088A is compliant with the Layerscape Chassis Generation 3. 60 61Features summary: 62 - 8 32-bit / 64-bit ARM v8 Cortex-A53 CPUs 63 - Cores are in 2 cluster of 4-cores each 64 - 1MB L2 - Cache per cluster 65 - Cache coherent interconnect (CCI-400) 66 - 1 64-bit DDR4 SDRAM memory controller with ECC 67 - Data path acceleration architecture 2.0 (DPAA2) 68 - 4-Lane 10GHz SerDes comprising of WRIOP 69 - 4-Lane 10GHz SerDes comprising of PCI, SATA, uQE(TDM/HLDC/UART) 70 - Ethernet interfaces: SGMIIs, RGMIIs, QSGMIIs, XFIs 71 - QSPI, SPI, IFC2.0 supporting NAND, NOR flash 72 - 3 PCIe3.0 , 1 SATA3.0, 2 USB3.0, 1 SDXC, 2 DUARTs etc 73 - 2 DUARTs 74 - 4 I2C, GPIO 75 - Thermal monitor unit(TMU) 76 - 4 Flextimers and 1 generic timer 77 - Support for hardware virtualization and partitioning enforcement 78 - QorIQ platform's trust architecture 3.0 79 - Service processor (SP) provides pre-boot initialization and secure-boot 80 capabilities 81 82LS2080A 83-------- 84The LS2080A integrated multicore processor combines eight ARM Cortex-A57 85processor cores with high-performance data path acceleration logic and network 86and peripheral bus interfaces required for networking, telecom/datacom, 87wireless infrastructure, and mil/aerospace applications. 88 89The LS2080A SoC includes the following function and features: 90 91 - Eight 64-bit ARM Cortex-A57 CPUs 92 - 1 MB platform cache with ECC 93 - Two 64-bit DDR4 SDRAM memory controllers with ECC and interleaving support 94 - One secondary 32-bit DDR4 SDRAM memory controller, intended for use by 95 the AIOP 96 - Data path acceleration architecture (DPAA2) incorporating acceleration for 97 the following functions: 98 - Packet parsing, classification, and distribution (WRIOP) 99 - Queue and Hardware buffer management for scheduling, packet sequencing, and 100 congestion management, buffer allocation and de-allocation (QBMan) 101 - Cryptography acceleration (SEC) at up to 10 Gbps 102 - RegEx pattern matching acceleration (PME) at up to 10 Gbps 103 - Decompression/compression acceleration (DCE) at up to 20 Gbps 104 - Accelerated I/O processing (AIOP) at up to 20 Gbps 105 - QDMA engine 106 - 16 SerDes lanes at up to 10.3125 GHz 107 - Ethernet interfaces 108 - Up to eight 10 Gbps Ethernet MACs 109 - Up to eight 1 / 2.5 Gbps Ethernet MACs 110 - High-speed peripheral interfaces 111 - Four PCIe 3.0 controllers, one supporting SR-IOV 112 - Additional peripheral interfaces 113 - Two serial ATA (SATA 3.0) controllers 114 - Two high-speed USB 3.0 controllers with integrated PHY 115 - Enhanced secure digital host controller (eSDXC/eMMC) 116 - Serial peripheral interface (SPI) controller 117 - Quad Serial Peripheral Interface (QSPI) Controller 118 - Four I2C controllers 119 - Two DUARTs 120 - Integrated flash controller (IFC 2.0) supporting NAND and NOR flash 121 - Support for hardware virtualization and partitioning enforcement 122 - QorIQ platform's trust architecture 3.0 123 - Service processor (SP) provides pre-boot initialization and secure-boot 124 capabilities 125 126LS1012A 127-------- 128The LS1012A features an advanced 64-bit ARM v8 Cortex- 129A53 processor, with 32 KB of parity protected L1-I cache, 13032 KB of ECC protected L1-D cache, as well as 256 KB of 131ECC protected L2 cache. 132 133The LS1012A SoC includes the following function and features: 134 - One 64-bit ARM v8 Cortex-A53 core with the following capabilities: 135 - ARM v8 cryptography extensions 136 - One 16-bit DDR3L SDRAM memory controller, Up to 1.0 GT/s, Supports 137 16-/8-bit operation (no ECC support) 138 - ARM core-link CCI-400 cache coherent interconnect 139 - Packet Forwarding Engine (PFE) 140 - Cryptography acceleration (SEC) 141 - Ethernet interfaces supported by PFE: 142 - One Configurable x3 SerDes: 143 Two Serdes PLLs supported for usage by any SerDes data lane 144 Support for up to 6 GBaud operation 145 - High-speed peripheral interfaces: 146 - One PCI Express Gen2 controller, supporting x1 operation 147 - One serial ATA (SATA Gen 3.0) controller 148 - One USB 3.0/2.0 controller with integrated PHY 149 - One USB 2.0 controller with ULPI interface. . 150 - Additional peripheral interfaces: 151 - One quad serial peripheral interface (QuadSPI) controller 152 - One serial peripheral interface (SPI) controller 153 - Two enhanced secure digital host controllers 154 - Two I2C controllers 155 - One 16550 compliant DUART (two UART interfaces) 156 - Two general purpose IOs (GPIO) 157 - Two FlexTimers 158 - Five synchronous audio interfaces (SAI) 159 - Pre-boot loader (PBL) provides pre-boot initialization and RCW loading 160 - Single-source clocking solution enabling generation of core, platform, 161 DDR, SerDes, and USB clocks from a single external crystal and internal 162 crystaloscillator 163 - Thermal monitor unit (TMU) with +/- 3C accuracy 164 - Two WatchDog timers 165 - ARM generic timer 166 - QorIQ platform's trust architecture 2.1 167 168LS1046A 169-------- 170The LS1046A integrated multicore processor combines four ARM Cortex-A72 171processor cores with datapath acceleration optimized for L2/3 packet 172processing, single pass security offload and robust traffic management 173and quality of service. 174 175The LS1046A SoC includes the following function and features: 176 - Four 64-bit ARM Cortex-A72 CPUs 177 - 2 MB unified L2 Cache 178 - One 64-bit DDR4 SDRAM memory controllers with ECC and interleaving 179 support 180 - Data Path Acceleration Architecture (DPAA) incorporating acceleration the 181 the following functions: 182 - Packet parsing, classification, and distribution (FMan) 183 - Queue management for scheduling, packet sequencing, and congestion 184 management (QMan) 185 - Hardware buffer management for buffer allocation and de-allocation (BMan) 186 - Cryptography acceleration (SEC) 187 - Two Configurable x4 SerDes 188 - Two PLLs per four-lane SerDes 189 - Support for 10G operation 190 - Ethernet interfaces by FMan 191 - Up to 2 x XFI supporting 10G interface (MAC 9, 10) 192 - Up to 1 x QSGMII (MAC 5, 6, 10, 1) 193 - Up to 4 x SGMII supporting 1000Mbps (MAC 5, 6, 9, 10) 194 - Up to 3 x SGMII supporting 2500Mbps (MAC 5, 9, 10) 195 - Up to 2 x RGMII supporting 1000Mbps (MAC 3, 4) 196 - High-speed peripheral interfaces 197 - Three PCIe 3.0 controllers, one supporting x4 operation 198 - One serial ATA (SATA 3.0) controllers 199 - Additional peripheral interfaces 200 - Three high-speed USB 3.0 controllers with integrated PHY 201 - Enhanced secure digital host controller (eSDXC/eMMC) 202 - Quad Serial Peripheral Interface (QSPI) Controller 203 - Serial peripheral interface (SPI) controller 204 - Four I2C controllers 205 - Two DUARTs 206 - Integrated flash controller (IFC) supporting NAND and NOR flash 207 - QorIQ platform's trust architecture 2.1 208 209LS2088A 210-------- 211The LS2088A integrated multicore processor combines eight ARM Cortex-A72 212processor cores with high-performance data path acceleration logic and network 213and peripheral bus interfaces required for networking, telecom/datacom, 214wireless infrastructure, and mil/aerospace applications. 215 216The LS2088A SoC includes the following function and features: 217 218 - Eight 64-bit ARM Cortex-A72 CPUs 219 - 1 MB platform cache with ECC 220 - Two 64-bit DDR4 SDRAM memory controllers with ECC and interleaving support 221 - One secondary 32-bit DDR4 SDRAM memory controller, intended for use by 222 the AIOP 223 - Data path acceleration architecture (DPAA2) incorporating acceleration for 224 the following functions: 225 - Packet parsing, classification, and distribution (WRIOP) 226 - Queue and Hardware buffer management for scheduling, packet sequencing, and 227 congestion management, buffer allocation and de-allocation (QBMan) 228 - Cryptography acceleration (SEC) at up to 10 Gbps 229 - RegEx pattern matching acceleration (PME) at up to 10 Gbps 230 - Decompression/compression acceleration (DCE) at up to 20 Gbps 231 - Accelerated I/O processing (AIOP) at up to 20 Gbps 232 - QDMA engine 233 - 16 SerDes lanes at up to 10.3125 GHz 234 - Ethernet interfaces 235 - Up to eight 10 Gbps Ethernet MACs 236 - Up to eight 1 / 2.5 Gbps Ethernet MACs 237 - High-speed peripheral interfaces 238 - Four PCIe 3.0 controllers, one supporting SR-IOV 239 - Additional peripheral interfaces 240 - Two serial ATA (SATA 3.0) controllers 241 - Two high-speed USB 3.0 controllers with integrated PHY 242 - Enhanced secure digital host controller (eSDXC/eMMC) 243 - Serial peripheral interface (SPI) controller 244 - Quad Serial Peripheral Interface (QSPI) Controller 245 - Four I2C controllers 246 - Two DUARTs 247 - Integrated flash controller (IFC 2.0) supporting NAND and NOR flash 248 - Support for hardware virtualization and partitioning enforcement 249 - QorIQ platform's trust architecture 3.0 250 - Service processor (SP) provides pre-boot initialization and secure-boot 251 capabilities 252 253LS2088A SoC has 3 more similar SoC personalities 2541)LS2048A, few difference w.r.t. LS2088A: 255 a) Four 64-bit ARM v8 Cortex-A72 CPUs 256 2572)LS2084A, few difference w.r.t. LS2088A: 258 a) No AIOP 259 b) No 32-bit DDR3 SDRAM memory 260 c) 5 * 1/10G + 5 *1G WRIOP 261 d) No L2 switch 262 2633)LS2044A, few difference w.r.t. LS2084A: 264 a) Four 64-bit ARM v8 Cortex-A72 CPUs 265 266LS2081A 267-------- 268LS2081A is 40-pin derivative of LS2084A. 269So feature-wise it is same as LS2084A. 270Refer to LS2084A(LS2088A) section above for details. 271 272It has one more similar SoC personality 2731)LS2041A, few difference w.r.t. LS2081A: 274 a) Four 64-bit ARM v8 Cortex-A72 CPUs 275 276LX2160A 277-------- 278The QorIQ LX2160A processor is built in the 16FFC process on 279the Layerscape architecture combining sixteen ARM A72 processor 280cores with advanced, high-performance datapath acceleration and 281network, peripheral interfaces required for networking, wireless 282infrastructure, storage, and general-purpose embedded applications. 283 284LX2160A is compliant with the Layerscape Chassis Generation 3.2. 285 286The LX2160A SoC includes the following function and features: 287 Sixteen 32-bit / 64-bit ARM v8 A72 CPUs 288 Cache Coherent Interconnect Fabric (CCN508 aka “Eliot”) 289 Two 64-bit 3.2GT/s DDR4 SDRAM memory controllers with ECC. 290 Data path acceleration architecture (DPAA2) 291 24 Serdes lanes at up to 25 GHz 292 Ethernet interfaces 293 Single WRIOP tile supporting 130Gbps using 18 MACs 294 Support for 10G-SXGMII (aka USXGMII). 295 Support for SGMII (and 1000Base-KX) 296 Support for XFI (and 10GBase-KR) 297 Support for CAUI4 (100G); CAUI2 (50G) and 25G-AUI(25G). 298 Support for XLAUI (and 40GBase-KR4) for 40G. 299 Support for two RGMII parallel interfaces. 300 Energy efficient Ethernet support (802.3az) 301 IEEE 1588 support. 302 High-speed peripheral interfaces 303 Two PCIe Gen 4.0 8-lane controllers supporting SR-IOV, 304 Four PCIe Gen 4.0 4-lane controllers. 305 Four serial ATA (SATA 3.0) controllers. 306 Two USB 3.0 controllers with integrated PHY 307 Two Enhanced secure digital host controllers 308 Two Controller Area Network (CAN) modules 309 Flexible Serial peripheral interface (FlexSPI) controller. 310 Three Serial peripheral interface (SPI) controllers. 311 Eight I2C Controllers. 312 Four PL011 UARTs supporting two 4-pin UART ports or four 2-pin UART ports. 313 General Purpose IO (GPIO) 314 Support for hardware virtualization and partitioning (ARM MMU-500) 315 Support for GIC (ARM GIC-500) 316 QorIQ platform Trust Architecture 3.0 317 One Secure WatchDog timer and one Non-Secure Watchdog timer. 318 ARM Generic Timer 319 Two Flextimers 320 Debug supporting run control, data acquisition, high-speed trace, 321 performance/event monitoring 322 Thermal Monitor Unit (TMU) with +/- 2C accuracy 323 Support for Voltage ID (VID) for yield improvement 324 325LX2160A SoC has 2 more similar SoC personalities 3261)LX2120A, few difference w.r.t. LX2160A: 327 a) Twelve 64-bit ARM v8 Cortex-A72 CPUs 328 3292)LX2080A, few difference w.r.t. LX2160A: 330 a) Eight 64-bit ARM v8 Cortex-A72 CPUs 331